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我 和 Java “很 有 缘 ，2003 年 在 富士 通 南大 实习 的 时 候 ， 就 开始 用 
Struts/JSP/Hibernate/MySQL 做 第 一 个 Java 项 目 
SPIF (http://www .fujitsu.com/cn/products/software/applications/spif/) 。 

工作 之 后 ， 主 要 做 J2EE 的 开发 ， 并 开始 慢 慢 接触 和 使 用 Spring。 加 
入 EMC 之 后 ， 很 有 幸 和 Spring 成 为 一 个 大 家 庭 “EMC 收购 了 
VMware,VMware 收 购 了 Spring) 。2012 年 ， 我 和 Spring Data/XD 的 负责 
人 Mark Pollack 在 中 国 开 过 一 次 小 会 ， 和 他 探讨 了 一 些 关 于 Data Pipeline 
的 想法 。 后 来 我 也 看 了 很 多 Josh Long( 龙 应 春 ) 的 演讲 视频 ， 并 在 2016 
年 终于 有 六 能 够 与 他 在 一 个 技术 大 会 上 同 场 演讲 ， 并 在 会 议 之 后 做 了 很 
多 深入 沟通 。 

2015 年 上 半年 ， 我 谈 了 两 本 书 : The Phoenix Project 和 Migrating to 
Cloud-Native Application Architectures， 让 我 对 DevOps、 微 服务 和 云 原 
ee 也 让 我 对 Netflix 的 那 套 OSS 套 件 有 了 一 个 初步 
印象 。 


我 是 在 2015 年 9 月 加 入 矿 袋 理财 之 后 开始 接触 Spring Boot 的 ， 试 用 之 
后 感觉 它 很 神奇 ， 再 也 没有 被 Spring 之 前 那些 烦琐 配置 所 束缚 。 当 时 正 
好 和 一 个 架构 师 讨 论 要 做 一 个 项 目的 升级 改造 ， 决 定 采 用 Spring Boot 和 
微服 务 架 构 。 开 始 的 时 候 ， 服 务 治理 还 是 用 了 Dubbo。 之 后 因为 对 
Spring 。 Cloud 有 了 比较 深刻 的 认识 ， 在 之 后 一 个 全 新 项 目 上 ， 我 们 完全 
按照 微服 务 架 构 ， 使 用 Spring Boot 和 Cloud 进 行 开 发 ， 并 采用 CICD 自 动 
化 流程 和 容器 化 部 署 。 

因为 使 用 了 Spring Cloud， 让 我 对 Spring ” Cloud 的 相关 信息 特别 关 
注 。 一 个 偶然 的 机 会 ， 我 认识 了 Spring ”Cloud 中 国 社区 的 负责 人 许 进 、 
惟 永 超 〈 本 书 作 者 ) 和 周 立 ， 探 讨 了 很 多 使 用 Spring ”Cloud 的 经 验 ， 感 
觉 与 他 们 和 Spring Cloud 相 见 恨 晚 。 

翟 永超 本 人 写 了 很 多 关于 Spring ”Cloud 使 用 的 博客 ， 不 同 于 一 般 作 
者 ， 他 写 的 内 容 更 加 贴近 实际 ， 是 自己 工作 经 验 的 深刻 总 结 ， 可 以 拿 来 
直接 用 于 生产 。 

有 一 次 我 们 聊 到 关于 配置 中 心 (Spring Cloud Config) 如 何在 生产 中 
使 用 ， 他 解答 了 我 很 多 问题 ， 并 告诉 我 他 写 了 一 本 书 ， 书 中 就 会 包含 这 
些 内 容 。 这 让 我 对 这 本 书 充 满 期 待 。 后 面 也 有 幸 见 到 了 本 人 ， 一 个 瘦 瘦 
高 高 的 书生 ， 一 看 驶 是 一 个 很 有 内 涵 的 技术 人 。 畅 聊 之 后 ， 翟 永超 就 把 
书 发 给 了 我 ， 让 我 先睹为快 。 

















我 把 翟 永超 的 书 仔细 拜 谈 了 一 裔 ， 最 大 的 收获 就 是 让 我 对 Spring 
Cloud 的 认识 又 上 升 了 一 个 层次 。 我 之 前 对 Spring Cloud 的 理解 更 多 的 是 
知 其 然 ， 但 是 却 不 知道 其 所 以 然 ， 对 Spring ”Cloud 里面 的 逻辑 知之 其 
少 。 而 读 了 惟 永 超 的 《Spring Cloud 微 服务 实战 》 一 书后 ， 让 我 对 Spring 
Cloud 各 个 组 件 的 认识 提升 了 一 个 层次 ， 同 时 也 让 我 对 Spring Cloud 各 个 
组 件 的 实现 原理 有 了 初步 的 认识 ， 因 此 我 建议 所 有 打算 将 Spring Cloud 

王 

DaoCloud 首席 架构 师 

2017 年 3 月 
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2016 年 10 月 开始 ， 我 在 冰 鉴 科技 负责 微服 务 架 构 迁移 相关 的 调研 和 
筹建 工作 。 我 比较 了 Dubbo、Dubbox、Motan、Spring Cloud 等 框架 后 ， 
最 终 锁定 在 Spring ” Cloud 上 。 这 是 一 个 非常 年 轻 的 框架 ， 关 于 它 的 中 文 
文档 少 之 又 少 ， 更 不 用 说 有 深度 的 技术 干货 了 。 

当 我 的 团队 在 利用 搜索 引 苟 进行 相关 检索 时 ， 永 超 的 技术 博客 十 分 
显眼 地 排 在 了 前 列 ， 我 非常 感激 他 贡献 的 这 个 系列 的 文章 ， 这 在 我 们 团 
队 做 微服 务 架 构 迁 移 的 工作 中 ， 起 到 了 关键 作用 。 后 来 有 一 天 ， 我 俩 在 
一 个 架构 群 中 相识 ， 一 番 讨 论 后 发 现 是 博 主 本 人 并 且 他 有 写 书 计 划 时 ， 

告诉 了 我 的 团队 ， 我 们 不 谍 而 合 地 诀 定 要 在 该 书 出 版 时 迅速 收入 宫 
中 ， 做 到 人 手 一 本 。 而 今天 对 于 我 来 说 更 是 非常 薪 和 地， 能 够 给 永超 的 新 
书写 推荐 序 。 

Spring Cloud 是 一 个 微服 务 架 构 实施 的 综合 性 解决 框架 ， 而 在 如 何 构 
建 微服 务 的 选择 上 ， 由 于 我 们 团队 是 从 SSM (Springt+Spring 
MVC+MyBatis) 框架 开始 演进 的 ， 基 于 让 演进 中 改动 最 小 的 初 袁 ， 我 
们 决定 使 用 Spring Boot 做 微服 务 构建 。 我 们 从 对 Spring Boot 的 调研 开始 
就 一 直 关 注 着 永超 的 技术 博客 ， 在 第 一 次 接触 Spring Boot 的 时 候 就 被 
它 “ 习 惯 优 于 配置 ”的 设计 概念 深 深 吸 引 ， 这 无 疑 简化 了 做 业务 逻辑 开发 
同事 的 工作 量 ， 也 使 得 他 们 可 以 不 用 关注 配置 细节 。 本 书 中 也 有 关于 
Spring Boot 基 础 知识 的 详细 讲解 以 及 一 个 案例 工程 带 你 快速 构建 属于 你 
的 第 一 个 微服 务 。 

如 开头 所 述 ， 为 了 将 系统 微服 务 化 ， 我 们 也 一 直 在 对 Spring Cloud 
进行 相关 调研 。 这 本 书 也 是 国内 市 场 上 为 数 不 多 的 、 全 面 讲 解 “Spring 
Cloud 微服 务 的 中 文 图 书 。 本 书 详细 讲解 了 Spring Cloud 生态 的 各 类 组 
件 ， 涵 盖 了 服务 治理 组 件 Eureka、 客 户 端 负载 均衡 组 件 Ribbon、 服 务 容 
错 保 护 组 件 Hystrix、 声 明 式 服务 调用 组 件 ”Feign、API 网 关 治 理 组 件 
Zuul、 分 布 式 配置 中 心 组件 Config、 消 息 总 线 组 件 Bus、 消 息 驱 动 组 件 
Stream、 分 布 式 服务 跟踪 组 件 _Sleuth。 这 包含 了 我 们 在 实施 微服 务 中 需 
要 深入 了 解 的 各 个 轮子 ， 是 一 本 需要 仔细 研 谈 、 反 复 阅 读 的 精品 之 作 。 

最 后 ， 预 祝 永超 在 Spring Cloud 的 学 习 和 工作 中 再 创 佳 绩 ， 也 和 希望 读 
者 朋友 能 够 在 阅读 完 本 书后 快速 地 搭建 好 实施 微服 务 过 程 中 的 基础 脚 手 
架 ， 并 在 未 来 工作 中 能 够 将 团队 的 一 些 实践 通过 Spring ”Cloud 中 国 社区 
进行 交流 ， 为 开源 贡献 自己 的 一 份 力量 。 


朱 清 














冰 鉴 科技 信息 技术 部 总 监 
Spring Cloud 中 国 社区 联合 创始 人 
2017.03.27 
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收 到 本 书 作 者 伏 永 超 的 邀请 为 这 本 书写 推荐 序 ， 其 实 我 是 很 诺 慎 
的 。 抱 着 对 读者 负责 、 对 技术 严 谍 的 态度 ， 不 能 在 完全 不 懂 Spring 
Cloud 的 基础 上 妄 加 评论 。 就 像 2009 年 的 云 计算 和 现在 的 大 数据 ，“Big 
data is like teenage sex: everyone talks about it,nobody really knows how to 
do it,everyone thinks everyone else is doing it,so everyone claims they are 
doing it”。 所 以 我 概 读 了 书 中 的 内 容 ， 的 确 是 一 本 好 书 ， 特 别 是 在 基于 
技术 灾 中 的 首 述 中 又 个 和 对 "全 服 务 化 "理论 层面 的 讲解 以 及 发 展演 进 过 
旺 的 说 明 。 

结合 在 云 计 算 行业 中 为 大 量 企业 级 客户 做 的 服务 案例 , “集中 化 ”的 
系统 染 构 确实 在 企业 级 客户 业务 中 受到 越 来 越 多 的 挑战 ， 随 着 业务 变化 
对 IT 需求 的 不 断 增 加 ， 处 于 逐渐 失控 的 状态 。CIO 们 受到 越 来 越 大 的 挑 
战 ， 布 望 做 到 数据 驱动 业务 ， 那 第 一 个 阶段 就 要 做 去 中 心 化 的 改造 。 如 
书 中 所 阐述 , “微服 务 化 "其实 并 不 是 简单 的 技术 革新 ， 而 是 对 团队 组 
织 ， 系 统 架 构 ， 系 统 研 发 ， 自 动 化 测试 、 发 布 、 运 维 都 提出 了 一 系列 的 
变革 要 求 。 所 以 我 觉得 ， 不 管 是 架构 师 、 运 维 经 理 、 研 发 主管 还 是 CIO 
都 可 以 从 本 书 中 有 所 收获 。 

同样 ， 阿 里 云 的 企业 级 中 间 件 EDAS (基于 阿里 系 的 Dubbo 开源 项 
目 ) 配合 强大 的 飞天 云 平 台 与 Docker 服 务 的 支持 ， 在 大 中 型 企业 客户 业 
务 中 得 到 更 多 的 验证 ， 如 森马 服饰 、 来 伊 份 、 正 佳 广场 、 中 石化 的 易 派 
客 电 商 平 台 等 。 与 这 些 商 业 化 的 中 间 件 产品 相 比 ，Spring ”Cloud 得 到 了 
更 多 热衷 开源 项 目的 人 的 文 持 ， 相 信 在 有 足够 团队 技术 能 力 的 保障 下 ， 
也 会 取得 越 来 越 多 的 成 功 案例 。 书 如 其 人 ， 值 得 认真 拜读 ， 我 会 推荐 给 
更 多 的 人 ， 为 汰 永超 点 赞 。 

李 俊 涛 


上 海 驻 云 科技 执行 总 监 
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本 书 从 时 下 流行 的 微服 务 架 构 概 念 出 发 ， 结 合 Spring Cloud 的 解决 方 
案 ， 深 入 浅 出 地 剖析 了 其 在 构建 微服 务 架 构 中 所 需 的 各 个 基础 设施 和 技 
术 要 点 ， 包 括 服务 治理 、 容 错 保护 、API 网关、 配置 管理 、 消 息 总 线 
等 。 作 者 不 仅 对 如 何 使 用 各 个 组 件 做 了 详细 介绍 ， 还 从 原理 上 做 了 很 多 
分 析 ， 可 以 帮助 读者 更 好 地 理解 Spring ” ”Cloud 的 运行 原理 ， 这 有 助 于 我 
们 在 实战 中 有 效 地 排 错 和 做 进一步 扩展 。 本 书 是 微服 务 架 构 方面 非 芝 不 
错 的 实战 书籍 ， 强 烈 推 荐 正在 做 微服 务实 践 或 打算 实施 微服 务 的 团队 作 





为 参考 资料 。 
南 志文 
百联 全 渠道 研发 总 监 


Spring Cloud 的 诞生 对 于 没有 足够 资金 投入 或 者 技术 储备 实力 的 技术 
团队 是 一 种 福音 。 利 用 Spring ”Cloud 的 一 站 式 解 决 方案 ， 可 以 很 轻松 地 
搭建 起 微服 务 架构 的 软件 系统 ， 大 大 减少 了 开发 成 本 ， 从 容 应 对 业务 的 
快速 发 展 。 本 书 是 国内 第 一 本 Spring ”Cloud 的 实战 书籍 ， 给 我 带 来 了 无 
限 惊喜 。 作 者 由 浅 入 深 地 讲解 了 基于 Spring ”Cloud 构建 微 服务 所 需要 的 
各 个 核心 组 件 ， 并 配 有 大 量 实战 代码 ， 理 论 和 实践 兼备 ， 读 后 收获 鼎 
丰 。 强 烈 推 荐 给 每 一 位 对 Spring Cloud 感 兴趣 或 是 打算 使 用 Spring Cloud 
的 技术 人 员 阅 读 。 

覃 罗 春 

德比 软件 产品 开发 负责 人 

当下 最 火 的 词 无 外 乎 就 是 “微服 务 ” 了 ， 但 是 很 多 创业 公司 想 要 实现 
微服 务 架 构 体 系 还 需要 做 很 多 方面 的 工作 才 可 以 逐步 实现 ， 所 需 花 费 的 
成 本 还 是 较 大 的 。 而 近年 来 Spring Boot/Cloud 生态 架构 体系 的 出 现 为 行 
业 提 供 了 一 站 式 解 决 方案 ， 解 决 了 不 少 公司 的 架构 选 型 和 维护 方面 的 难 
题 。 本 书 是 国内 第 一 本 以 Spring Cloud 为 技术 蓝本 的 微服 务 类 实战 书 
籍 ， 不 仅 结合 实际 案例 介绍 了 Spring ” ”Cloud 的 使 用 ， 还 从 源码 的 角度 深 
0 原理 实现 ， 强 烈 推 荐 每 一 位 开发 者 和 架构 师 收藏 和 学 习 。 

至 超 

合 众 支 付 资深 技术 专家 

随 着 微服 务 架 构 的 兴起 ， 企 业 IT 架 构 开 始 变 单 ， 国 内 出 现 首 批 微服 
务实 战 布 道 者 。 本 书 作 者 性 永 超 ， 作 为 Spring ” ”Cloud 中国 社区 联合 发 起 
人 和 国内 首 批 Spring ” Cloud 实践 与 布道 者 ， 友 表 的 博文 超过 数 百 万 次 访 
问 量 。 他 的 《Spring Cloud 微 服务 实战 》 一 书 ， 包 含 大 量 生产 实战 经 




















验 ， 把 Spring Cloud 第 用 组 件 通 过 和 守 例 训 析 ， 可 帮助 企业 和 开发 者 快速 
实施 微服 务 架 构 。 

许 进 (xujin.org) 

Spring Cloud 中 国 社区 创始 人 

中 间 件 高 级 研发 工程 师 

近 几 年 ， 微 服务 概念 逐渐 深入 人 心 ， 国 内 各 家 互联 网 公司 都 引入 了 
相应 的 实践 。 而 被 应 用 最 多 的 束 是 Spring Cloud 这 和 套 被 戏称 为 “全 家 
桶 ”的 微服 务 框架 。 它 几乎 实现 了 微服 务 的 所 有 功能 ， 而 且 又 完美 符合 
微服 务 的 基础 理论 ， 可 帮助 大 家 提高 工作 效率 。 但 是 ， 国 内 关于 Spring 
Cloud 的 中 文 资 料 相 对 比较 匮乏 ， 很 多 学 习 者 志 寻 入 门 而 不 得 。 在 此 大 
背景 下 ， 有 一 些 有 识 之 士 无 私 贡献 了 上 自己 的 绢 薄 之 力 ， 本 书 作 者 恰 永 超 
就 是 其 中 一 位 。 这 本 书 对 于 广大 需要 在 公司 中 实践 微服 务 的 人 们 来 说 绝 
对 是 一 本 可 以 快速 上 手 实现 微服 务 的 工作 手册 。 我 希望 这 本 书 犹 如 一 箱 
能 在 国内 互联 网 环境 的 土壤 中 生根 发 菠 ， 最 后 变 成 一 村 参天 大 
对 。 

关 峻 申 


上 海 青 客机 器 人 有 限 公 司 架 构 师 



































“微服 务 ? 架 构 在 这 几 年 被 广泛 传播 ， 变 得 非常 火热 ， 以 至 于 关于 微 
服务 架构 相关 的 开源 框架 和 工具 都 变 得 越 来 越 活 跃 ， 比 如 : Netflix 
OSS、Dubbo、Apache Thrift 等 。Spring Cloud 也 因为 Spring 社 区 在 企业 
0 受到 了 广大 染 构 师 与 开发 者 的 高 
度 关 注 。 

从 接触 Spring Cloud 开 始 ， 我 除了 被 其 庞大 的 项 目 结构 震撼 之 外 ， 还 
被 其 所 要 完成 的 远大 目标 所 吸引 。 访 项目 不 同 于 其 他 Spring 的 优秀 项 
目 ， 它 不 再 是 一 个 基础 框架 类 ， 而 是 一 个 更 高 层次 的 、 架 构 视 角 的 综合 
性 大 型 项 目 ， 其 目标 旨 在 构建 一 套 标准 化 的 微服 务 解 决 方案 ， 让 架构 
师 、 开 发 者 在 使 用 微服 务 理念 构建 应 用 系统 的 时 候 ， 面 对 各 个 环节 的 问 
题 都 可 以 找到 相应 的 组 件 来 处 理 。 引 用 网 友 戏 称 的 一 个 比喻 : Spring 
Cloud 可 以 说 是 Spring 社区 为 微服 务 架 构 提 供 的 一 个 “全 家 桶 ”和 套餐。 由 
于 “套餐 ”中 的 组 件 通 过 一 个 社区 进行 包装 与 整合 ， 使 得 “套餐 ”中 各 个 组 
件 之 间 的 配合 变 得 更 加 和 谐 ， 这 可 以 有 效 减少 我 们 在 组 件 的 选 型 和 整合 
所 以 它 可 以 帮助 我 们 快速 构建 起 基础 的 微服 务 架构 系 

虽然 ，Spring Cloud 提 供 了 很 多 我 们 期 竺 的 内 容 ， 但 是 因 其 涵盖 的 内 
容 非 常 广泛， 并 且 知 识 跨度 较 大 ， 因 此 对 于 很 多 初学 者 来 说 就 像 被 专业 
名 词 受 炸 了 一 样 ， 入 门 的 难度 也 就 大 大 提高 了 。 同 时 ， 中 文 文档 与 资料 
的 匮乏 ， 以 及 官方 文档 的 内 容 对 于 使 用 描述 并 不 够 细致 等 问题 ， 也 直接 
提升 了 使 用 者 的 学 习 门 榴 。 这 些 看 似 都 不 是 什么 大 问题 ， 但 是 却 在 一 定 
程度 上 阻碍 了 Spring ” Cloud 在 国内 的 推广 与 发 展 ， 毕 竞 任 何 一 项 优秀 技 
术 都 需要 有 大 批 的 实践 者 才能 得 到 不 断 优 化 、 完 善 和 发 扬 光 大 。 作 为 一 
名 Spring 社区 的 忠实 粉丝 和 长 期 实践 者 ， 自 然 硕 望 可 以 有 更 多 的 开发 者 
可 以 参与 到 Spring Cloud 的 使 用 和 贡献 中 来 ， 笔 者 也 束 戎 生 了 想 要 编写 
一 些 入 门 文章 的 念头 ， 一 方面 对 自身 知识 的 掌握 做 一 些 整理 ， 另 一 方面 
也 希望 这 些 内 容 可 以 成 为 后 来 者 的 学 习 资 料 。 于 是 就 开始 坚持 着 写 了 一 
些 基 础 的 入 门 文 章 和 示例 ， 没 有 想到 会 受到 不 少 Spring 爱 好 者 的 持续 关 
注 ， 在 创建 了 相关 的 QQ 交流 群 之 后 ， 短 短 一 个 月 的 时 间 ， 交 流 群 的 人 
数 就 突破 了 1000 人 。 由 于 在 交流 过 程 中 发 现 很 多 问题 重复 出 现 ， 而 这 些 
问题 并 没有 得 到 很 好 的 整理 ， 也 没有 办 法 被 搜索 引擎 收录 ， 于 是 就 创建 
了 Spring Cloud 中 文 社区 论坛 ， 以 帮助 收集 交流 过 程 中 提出 和 解决 的 各 
种 问题 ， 方 便 将 来 学 习 者 可 以 搜索 到 这 些 前 人 踩 过 的 坑 。 
































之 后 ， 有 有 季 在 电子 工业 出 版 社 计算 机 出 版 分 社 的 张 春 十 先生 的 邀请 
下 ， 开 始 编写 这 本 关于 Spring Cloud 的 入 门 书籍 。 在 这 本 书 的 编写 期 
间 ， 由 于 工作 、 家 庭 等 因素 ， 使 得 与 大 家 交流 的 时 间 变 得 越 来 越 少 ， 但 
好 在 有 诸多 网 友和 热心 爱好 者 帮忙 一 起 维护 着 交流 群 与 论坛 ， 为 大 家 提 
供 了 很 多 宝贵 的 学 习 资 源 ， 我 也 从 中 得 到 了 不 少 局 发 和 收获 。 同 时 ， 感 
谢 后 来 建议 并 牵头 整合 目前 国内 Spring ” ”Cloud 学习 资源 的 许 进 ， 他 在 此 
期 间 承 担 了 很 多 沟通 和 网 站 维护 工作 ， 为 Spring ” Cloud 中国 社区 付出 了 
不 少 精力 ， 后 续 我 也 会 重新 加 入 进来 ， 继 续 编 写 在 线 免 费 入 门 教程 ， 以 
帮助 更 多 的 爱好 者 快速 入 门 Spring _ Cloud。 我 们 也 欢迎 更 多 的 爱好 者 参 
以 帮助 Spring ” Cloud 在 国内 被 更 好 地 应 
用 与 成 长 。 

轻松 注册 成 为 博文 视点 社区 用 户 (www.broadview.com.cn) ， 即 可 
享受 以 下 服务 : 

0 本 书 所 提供 的 示例 代码 及 资源 文件 均 可 在 “下 载 资源 ”处 
下 载 。 
提交 勘误 : 您 对 书 中 内 容 的 修改 意见 可 在 “提交 勘误 ”处 提交 ， 寿 被 
采纳 ， 将 获 赠 博 文 视点 社区 积分 (在 您 购买 电子 书 时 ， 积 分 可 用 来 抵 扣 
相应 金额 〉。 

与 作者 交流 : 在 页 面 下 方 “ 读 者 评论 ”处 留 下 您 的 疑问 或 观点 ， 与 作 
者 和 其 他 读者 一 同学 习 交 流 。 

页 面 入 口 : http://www.broadview.com.cn/31301 









































ing Cloud Sleuth 


第 1 章 基础 知识 


在 进行 Spring Cloud 的 具体 内 容 介 绍 之 前 ， 我 们 移 通 过 本 章 学 习 一 些 
关于 微服 务 架 构 以 及 Spring Cloud 的 基础 知识 。 对 Spring Cloud 能 够 解决 
的 具体 问题 有 一 个 大 致 的 了 解 ， 以 帮助 我 们 更 好 地 理解 后 续 章 节 对 各 个 
组 件 的 介绍 。 


什么 是 微服 务 架 构 


“微服 务 ” 一 词 源 于 Martin Fowler 的 名 为 Microservices 的 博文 ， 可 以 在 
他 的 官方 博客 上 找到 : 
http:/martinfowler.comyarticles/microservices.html。 

简单 地 说 ， 微 服务 是 系统 架构 上 的 一 种 设计 风格 ， 它 的 主旨 是 将 一 
个 原本 独立 的 系统 拆 分 成 多 个 小 型 服务 ， 这 些小 型 服务 都 在 各 上 自 独 立 的 
进程 中 运行 ， 服 务 之 间 通 过 基于 HTTP 的 RESTful API 进 行 通信 协作 。 被 
拆 分 成 的 每 一 个 小 型 服务 都 围绕 着 系统 中 的 菜 一 项 或 一 些 厢 合 度 较 局 的 
业务 功能 进行 构建 ， 并 且 每 个 服务 都 维护 着 自身 的 数据 存储 、 业 务 开 
发 、 上 自动 化 测试 案例 以 及 独立 部 普 机 制 。 由 于 有 了 轻 量 级 的 通信 协作 基 
础 ， 所 以 这 些微 服务 可 以 使 用 不 同 的 语言 来 编写 。 





Us: 缠 隐 ] |X 另 | 

在 以 往 传统 的 企业 系统 架构 中 ， 我 们 针对 一 个 复杂 的 业务 需求 通常 
使 用 对 象 或 业务 类 型 来 构建 一 个 单 体 项 目 。 在 项 目 中 我 们 通常 将 需求 分 
为 三 个 主要 部 分 : 数据 库 、 服 务 端 处 理 、 前 庙 展现 。 在 业务 发 展 初期 ， 
由 于 所 有 的 业务 逻辑 在 一 个 应 用 中 ， 开 发 、 测 试 、 部 署 都 还 比较 容易 且 
方便 。 但 是 ， 随 着 企业 的 发 展 ， 系 统 为 了 应 对 不 同 的 业务 需求 会 不 断 为 
该 单 体 项 目 增 加 不 同 的 业务 模块 ， 同 时 随 着 移动 端 设备 的 进步 ， 前 端 展 
现 模块 已 经 不 仅仅 局 限于 Web 的 形式 ， 这 对 于 系统 后 端 向 前 端的 文 持 需 
要 更 多 的 接口 模块 。 单 体 应 用 由 于 面 对 的 业务 需求 更 为 宽泛 ， 不 断 扩 大 
的 需求 会 使 得 单 体 应 用 变 得 越 来 越 胱 肿 。 单 体 应 用 的 问题 就 逐渐 凸显 出 
来 ， 由 于 单 体 系统 部 署 在 一 个 进程 内 ， 往 往 我 们 修改 了 一 个 很 小 的 功 
能 ， 为 了 部 署 上 线 会 影响 其 他 功能 的 运行 。 并 且 ， 单 体 应 用 中 的 这 些 功 
能 模块 的 使 用 场景 、 并 发 量 、 消 耗 的 资源 类 型 都 各 有 不 同 ， 对 于 资源 的 
利用 又 互相 影响 ， 这 样 使 得 我 们 对 各 个 业务 模块 的 系统 容量 很 难 给 出 较 
为 准确 的 评估 。 所 以 ， 单 体系 统 在 初期 虽然 可 以 非常 方便 地 进行 开发 和 
使 用 ,但 是 随 着 系统 的 发 展 ， 维 护 成 本 会 变 得 越 来 越 大 ， 且 难以 控制 。 

为 了 解决 单 体系 统 变 得 庞大 胱 肿 之 后 产生 的 难以 维护 的 问题 ， 微 服 
务 架构 诞生 了 并 被 大 家 所 关注 。 我 们 将 系统 中 的 不 同 功能 模块 拆 分 成 多 
个 不 同 的 服务 ， 这 些 服务 都 能 够 独立 部 署 和 扩展 。 由 于 每 个 服务 都 运行 
在 自己 的 进程 内 ， 在 部 署 上 有 稳固 的 边界 ， 这 样 每 个 服务 的 更 新 都 不 会 
影响 其 他 服务 的 运行 。 同 时 ， 由 于 是 独立 部 署 的 ， 我 们 可 以 更 准确 地 为 











每 个 服务 评 佑 性 能 容量 ， 通 过 配合 服务 间 的 协作 流程 也 可 以 更 容易 地 发 
现 系统 的 瓶颈 位 置 ， 以 及 给 出 较为 准确 的 系统 级 性 能 容量 评 佑 。 


可 空 施 微 服务 





在 实施 微服 务 之 前 ， 我 们 必须 要 知道 ， 微 服务 虽然 有 非常 多 吸引 人 
的 优 斥 ， 但 是 也 因为 服务 的 拆 分 引发 了 诸多 原本 在 单 体 应 用 中 没有 的 问 
题 。 

e 运 维 的 新 挑战 : ”在 微服 务 架 构 中 ， 运 维 人 员 需 要 维护 的 进程 数量 
会 大 大 增加 。 有 条 不 率 地 将 这 些 进 程 编排 和 组 织 起 来 不 是 一 件 容易 的 
事 ， 传 统 的 运 维 人 员 往 往 很 难 适 应 这 样 的 改变 。 我 们 需要 运 维 人 员 有 更 
多 的 技能 来 应 对 这 样 的 挑战 ， 运 维 过 程 需 要 更 多 的 目 动 化 ， 这 束 要 求 运 
维 人 员 有 具备 一 定 的 开发 能 力 来 编排 运 维 过 程 并 让 它们 能 上 自动 运行 起 来 。 

e 接 口 的 一 致 性 : ”虽然 我 们 拆 分 了 服务 ， 但 是 业务 逻辑 上 的 依赖 并 
不 会 消除 ， 只 是 从 单 体 应 用 中 的 代码 依赖 变 为 了 服务 间 的 通信 依赖 。 而 
当 我 们 对 原 有 接口 进行 了 一 些 修改 ， 那 么 交互 方 也 需要 协调 这 样 的 改变 
来 进行 发 布 ， 以 保证 接口 的 正确 调用 。 我 们 需要 更 完善 的 接口 和 版 本 管 
理 ， 或 是 严格 地 遵循 开 闭 原则 。 

e 分 布 式 的 复杂 性 : 由 于 拆 分 后 的 各 个 微服 务 都 是 独立 部 署 并 运行 
在 各 目的 进程 内 ， 它 们 只 能 通过 通信 来 进行 协作 ， 所 以 分 布 式 环境 的 问 
题 都 将 是 微服 务 架 构 系 统 设计 时 需要 考虑 的 重要 因素 ， 比 如 网 络 延迟 、 
分 布 式 事务 、 蜡 步 消 息 等 。 

尽管 微服 务 架 构 有 很 多 缺点 和 问题 ， 但 是 其 实现 的 敏捷 开发 和 目 动 
化 部 署 等 优点 依然 被 广大 优秀 架构 师 和 开发 者 所 青睐 ， 所 以 解决 这 些 问 
题 就 是 这 几 年 诸多 架构 大 师 努 力 的 目标 。 

在 架构 师 对 于 一 个 大 型 系统 架构 的 设计 与 实施 的 过 程 中 ， 面 对 环 
境 、 资 源 、 团 队 等 各 种 因素 的 有 影响， 几乎 不 会 出 现 完 全 相同 的 架构 设 
计 。 对 于 微服 务 架 构 而 言 更 是 如 此 ， 由 于 并 没有 一 个 标准 或 正式 的 定 
义 ， 每 位 架构 师 都 根据 上 自身 理解 与 实际 情况 来 进行 设计 ， 并 在 发 展 的 过 
程 中 不 断 演化 与 完善 。 经 过 多 年 的 发 展 ，Martin Fowler 在 Microservices 
一 文中 ， 提 炬 出 了 微服 务 架 构 的 九 大 特性 ， 用 于 指导 大 家 设计 架构 。 

服务 组 件 化 

组 件 ， 是 一 个 可 以 独立 更 换 和 升级 的 单元 。 就 像 PC 中 的 CPU、 内 
存 、 显 卡 、 硬 盘 一 样 ， 独 立 且 可 以 更 换 升 级 而 不 影响 其 他 单元 。 

在 微服 务 架 构 中 ， 需 要 我 们 对 服务 进行 组 件 化 分 解 。 服 务 ， 是 一 种 
进程 外 的 组 件 ， 它 通过 HTTP 等 通信 协议 进行 协作 ， 而 不 是 像 传 统 组 件 
那样 以 散 入 的 方式 协同 工作 。 每 一 个 服务 都 独立 开发 、 部 署 ， 可 以 有 效 























避免 一 个 服务 的 修改 引起 整个 系统 的 重新 部 署 。 

打 一 个 不 恰当 的 比喻 ， 如 果 我 们 的 PC 组 件 以 服务 的 方式 构建 ， 那 
么 只 维护 主板 和 一 些 必要 外 设 之 后 ， 计 算 能 力 通过 一 组 外 部 服务 实现 ， 
我 们 只 需要 告诉 PC 从 哪个 地 址 来 获得 计算 能 力 ， 通 过 服务 定义 的 计算 
接口 来 实现 我 们 使 用 过 程 中 的 计算 需求 ， 从 而 实现 CPU 组 件 的 服务 化 。 
这 样 原本 复杂 的 PC 服务 得 到 了 轻 量化 的 实现 ， 我 们 甚至 只 需要 更 换 服 
务 地 址 就 能 升级 PC 的 计算 能 

按 业 务 组 织 团队 

当 决 定 如 何 划分 微服 务 时 ， 通 常 也 意味 着 我 们 要 开始 对 团队 进行 重 
新 规划 与 组 织 。 按 以 往 的 方式 ， 我 们 往往 会 从 技术 的 层面 将 团队 划分 为 
多 个 ， 比 如 DBA 团 队 、 运 维 团 队 、 后 端 团 队 、 前 端 团队 、 设 计 师 团队 
等 。 若 我 们 继续 按 这 种 方式 组 织 团 队 来 实施 微服 务 架构 开发 ， 当 有 一 个 
服务 出 现 问 题 需要 更 改 时 ， 可 能 是 一 个 非常 简单 的 变动 ， 比 如 对 人 物 擂 
述 增加 一 个 字段 ， 这 需要 从 数据 存储 开始 考虑 一 直到 设计 和 前 端 ， 虽 然 
大 家 的 修改 都 非常 小 ， 但 这 会 引起 跨 团 队 的 时 间 耗 费 和 预算 审批 。 

在 实施 微服 务 架 构 时 ， 需 要 采用 不 同 的 团队 分 割 方 法 。 由 于 每 一 个 
微服 务 都 是 针对 特定 业务 的 宽 栈 或 是 全 栈 实现 ， 既 要 负责 数据 的 持久 化 
存储 ， 又 要 负责 用 户 的 接口 定义 等 各 种 跨 专 业 领 域 的 职能 。 因 此 ， 面 对 
大 型 项 目的 时 候 ， 对 于 微服 务 团队 的 拆 分 更 加 建议 按 业 务 线 的 方式 进行 
拆 分 ， 一 方面 可 以 有 效 减少 服务 内 部 修改 所 产生 的 内 耗 ， 另 一 方面 ， 团 
队 边 界 可 以 变 得 更 为 清晰 。 

做 “产品 ”的 态度 

在 实施 微服 务 架 构 的 团队 中 ， 每 个 小 团队 都 应 该 以 做 产品 的 方式 ， 
对 其 产品 的 整个 生命 周期 负责 。 而 不 是 以 项 目的 模式 ， 以 完成 开发 与 交 
付 并 将 成 果 交 接 给 维护 者 为 最 终 目标 。 

开发 团队 通过 了 解 服务 在 具体 生产 环境 中 的 情况 ， 可 以 增加 他 们 对 
具体 业务 的 理解 ， 比 如 ， 很 多 时 候 ， 一 些 业 务 中 发 生 的 特殊 或 异常 情 
况 ， 很 可 能 产品 经 理 都 并 不 知晓 ， 但 细心 的 开发 者 很 容易 通过 生产 环境 
发 现 这 些 特殊 的 潜在 问题 或 需求 。 

所 以 ， 我 们 需要 用 做 “产品 ”的 态度 来 对 竺 每 一 个 微服 务 ， 持 续 关 注 
服务 的 运作 情况 ， 并 不 断 分 析 以 帮助 用 户 来 改善 业务 功能 。 

智能 端点 与 哑 管 道 

在 单 体 应 用 中 ， 组 件 间 直接 通过 函数 调用 的 方式 进行 交互 协作 。 而 
在 微服 务 架 构 中 ， 由 于 服务 不 在 一 个 进程 中 ， 组 件 间 的 通信 模式 发 生 了 
改变 ， 若 仅仅 将 原本 在 进程 内 的 方法 调用 改 成 RPC 方 式 的 调用 ， 会 导致 
微服 务 之 间 产 生 烦 珊 的 通信 ， 使 得 系统 表现 更 为 糟 米 ， 所 以 ， 我 们 需要 
更 粗 粒 度 的 通信 协议 。 


























在 微服 务 架构 中 ， 通 常会 使 用 以 下 两 种 服务 调用 方式 : 

e 第 一 种 ， 使 用 HTTP 的 RESTful API 或 轻 量 级 的 消息 发 送 协 议 ， 实 现 
言 恩 传递 与 服务 调用 的 触发 。 

e 第 二 种 ， 通 过 在 轻 量 级 消息 总 线 上 传递 消息 ， 类 似 RabbitMQ 等 一 
些 提 供 可 靠 异 步 交 换 的 中 间 件 。 

在 极度 强调 性 能 的 情况 下 ， 有 些 团 队 会 使 用 二 进 制 的 消息 发 送 协 
议 ， 例 如 protobuf。 即 使 是 这 样 ， 这 些 系统 仍然 会 呈现 出 “智能 端点 和 哑 
管道 ”的 特点 ， 这 是 为 了 在 易 读 性 与 高 效 性 之 间 取 得 平衡 。 当 然 大 多 数 
Web 应 用 或 企业 系统 并 不 需要 在 这 两 者 间 做 出 选择 ， 能 够 获得 易 读 性 已 
经 是 一 个 极 大 的 胜利 了 。 

Martin Fowler 

去 中 心 化 治理 

当 我 们 采用 集中 化 的 架构 治理 方案 时 ， 通 常 在 技术 平台 上 都 会 制定 
统一 的 标准 ， 但 是 每 一 种 技术 平台 都 有 其 短 板 ， 这 会 导致 在 碰 到 短 板 
时 ， 不 得 不 花费 大 力气 去 解决 ， 并 且 可 能 因为 其 底层 原因 解决 得 不 是 很 
好 ， 最 终 成 为 系统 的 瓶颈 。 

在 实施 微服 务 架 构 时 ， 通 过 采用 轻 量 级 的 契约 定义 接口 ， 使 得 我 们 
对 于 服务 本 身 的 具体 技术 平台 不 再 那么 敏感 ， 这 样 整个 微服 务 架 构 系 统 
中 的 各 个 组 件 就 能 针对 其 不 同 的 业务 特点 选择 不 同 的 技术 平台 ， 终 于 不 
会 出 现 杀 鸡 用 牛刀 或 是 杀 牛 用 指甲 钳 的 全 从 处 境 了 。 

不 是 每 一 个 问题 都 是 钵 子 ， 不 是 每 一 个 解决 方案 都 是 锤子 。 

去 中 心 化 管理 数据 

我 们 在 实施 微服 务 架 构 时 ， 都 希望 让 每 一 个 服务 来 管理 其 自 有 的 数 
据 库 ， 这 就 是 数据 管理 的 去 中 心 化 。 

在 去 中 心 化 过 程 中 ， 我 们 除了 将 原 数 据 库 中 的 存储 内 容 拆 分 到 新 的 
同 平台 的 其 他 数据 库 实例 中 之 外 如 把 原本 存储 在 MySQL 中 的 表 拆 分 
后 ， 存 储 到 多 个 不 同 的 MySQL 实 例 中 ) ， 也 可 以 将 一 些 具 有 特殊 结构 
或 业务 特性 的 数据 存储 到 一 些 其 他 技术 的 数据 库 实例 中 (如 把 日 志 信 息 
存储 到 MongoDB 中 或 把 用 户 登 录 信 息 存 储 到 Redis 中 ) 。 

虽然 数据 管理 的 去 中 心 化 可 以 让 数据 管理 更 加 细致 化 ， 通 过 采用 更 
合适 的 技术 可 让 数据 存储 和 性 能 达到 最 优 。 但 是 ， 由 于 数据 存储 于 不 同 
的 数据 库 实例 中 后 ， 数 据 一 致 性 也 成 为 微服 务 架 构 中 号 待 解 决 的 问题 之 
一 。 分 布 式 事务 本 壬 的 实现 难度 束 非 常 大 ， 所 以 在 微服 务 架 构 中 ， 我 们 
更 强调 在 各 服务 之 间 进 行 “无 事务 ”的 调用 ， 而 对 于 数据 一 至 性， 只 要 求 
数据 在 最 后 的 处 理 状态 是 一 致 的 即 可 ; 奎 在 过 程 中 发 现 错误 ， 通 过 补偿 
机 制 来 进行 处 理 ， 使 得 错误 数据 能 够 达到 最 终 的 一 致 性 。 

基础 设施 自动 化 
































近年 来 云 计 算 服 务 与 容器 化 技术 的 不 断 成 熟 ， 运 维基 础 设施 的 工作 
变 得 越 来 越 容易 。 但 是 ， 当 我 们 实施 微服 务 架构 时 ， 数 据 库 、 应 用 程序 
的 个 头 虽 然 都 变 小 了 ， 但 是 因为 拆 分 的 原因 ， 数 量 成 倍增 长 。 这 使 得 运 
维和 人员 需要 关注 的 内 容 也 成 倍增 长 ， 并 且 操 作 性 任务 也 会 成 倍增 长 ， 这 
些 问 题 天 没有 得 到 受 善 解决 ， 必 将 成 为 运 维和 人 员 的 蛋 梦 。 

所 以 ， 在 微服 务 架构 中 ， 务 必 从 一 开始 残 构 建 起 “持续 交付 ”平台 来 
支撑 整个 实施 过 程 ， 该 平台 需要 两 大 内 容 ， 缺 一 不 可 。 

e 目 动 化 测试 : ”每 次 部 署 前 的 强 心 剂 ， 尽 可 能 地 获得 对 正在 运行 的 
软件 的 信心 。 
e 目 动 化 部 轩 : 解放 烦琐 枯燥 的 重复 操作 以 及 对 多 环境 的 配置 管 


容错 设计 

在 单 体 应 用 中 ， 一 般 不 存在 单个 组 件 故 隐 而 其 他 部 件 还 在 运行 的 情 
况 ， 通 闸 是 一 挂 全 挂 。 而 在 微服 务 染 构 中 ， 由 于 服务 都 运行 在 独立 的 进 
程 中 ， 所 以 存在 部 分 服务 出 现 故 障 ， 而 其 他 服务 正常 运行 的 情况 。 比 
如 ， 当 正常 运作 的 服务 B 调 用 到 故障 服务 A 时 ， 因 故障 服务 A 没 有 返回 ， 
线程 挂 起 开始 等 每 ， 直 到 超时 才能 释放 ， 而 此 时 大 触及 服务 B 调 用 服务 
A 的 请 求 来 和 目 服务 C， 而 服务 C 频 繁 调用 服务 B 时 ， 由 于 其 依赖 服务 A， 
人 

单 的 营 延 。 

所 以 ， 在 微服 务 染 构 中 ， 快 速 检测 出 故障 源 并 尺 可 能 地 目 动 恢复 服 
务 是 必须 被 设计 和 考虑 的 。 通 党 ， 我 们 都 希望 在 每 个 服务 中 实现 监控 和 

志 记 录 的 组 件 ， 比 如 服务 状态 、 断 路 器 状态 、 吞 吐 量 、 网 络 延迟 等 关 
键 数据 的 仪表 盘 等 。 

演进 式 设 计 

通过 上 面 的 几 点 特征 ， 我 们 已 经 能 够 体会 到 ， 和 要 实施 一 个 完美 的 微 
服务 架构 ， 震 要 考虑 的 设计 与 成 本 并 不 小 ， 对 于 没有 足够 经 验 的 团队 来 
说 ， 甚 至 要 比 单 体 应 用 付出 更 多 的 代价 。 

所 以 ， 在 很 多 情况 下 ， 架 构 师 都 会 以 演进 的 方式 进行 系统 的 构建 。 
在 初期 ， 以 单 体系 统 的 方式 来 设计 和 实施 ， 一 方面 系统 体 量 初期 并 不 会 
很 大 ， 构 建 和 维护 成 本 都 不 高 。 另 一 方面 ， 初 期 的 核心 业务 在 后 期 通 种 
也 不 会 发 生 巨大 的 改变 。 随 着 系统 的 发 展 或 者 业务 的 需要 ， 架 构 师 会 将 
一 些 经 党 变动 或 是 有 一 定时 间 效 应 的 内 容 进行 微服 务 处 理 ， 并 逐渐 将 原 
来 在 单 体系 统 中 多 变 的 模块 逐步 拆 分 出 来 ， 而 稳定 不 太 变 化 的 模块 就 形 
成 一 个 核心 微服 务 存在 于 整个 染 构 之 中 。 
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为 什么 选择 Spring Cloud 


近 几 年 很 多 人 对 于 微服 务 架 构 的 热情 非常 蜗 ， 但 是 回 尖 看 “微服 
务 ” 被 提 及 也 有 很 多 年 了 。 无 数 的 架构 师 和 开发 者 在 实际 项 目 中 实践 该 
设计 理念 并 为 此 付出 了 诸多 努力 ， 同 时 也 分 享 了 他 们 在 微服 务 架 构 中 针 
对 不 同 应 用 场景 出 现 的 各 种 问题 的 各 种 解决 方案 和 开源 框架 ， 其 中 也 不 
乏 国 内 互联 网 企业 的 杰出 贡献 。 

e 服 务 治 理 : 阿里 巴巴 开源 的 Dubbo 和 当当 网 在 其 基础 上 扩展 的 
DubboX、Netflix 的 Eureka、Apache 的 Consul 等 。 

e 分 布 式 配置 管理 : 百度 的 Disconf、Netflix 的 Archaius、360 的 
QConf、Spring Cloud 的 Config、 淘 宝 的 Diamond 等 。 

e 批 量 任务 : 当当 网 的 Elastic-Job、LinkedIn 的 Azkaban、Spring 
Cloud 的 Task 等 。 


e 服 务 跟踪 : “京东 的 Hydra、Spring Cloud 的 Sleuth、Twitter 的 Zipkin 
从 
过 O 
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上 面 列举 了 一 些 在 实施 微服 务 染 构 初 期 ， 就 需要 被 我 们 考虑 进去 的 
问题 ， 以 及 针对 这 些 问 题 的 开源 解决 方 采 。 可 以 看 到 国内 、 国 外 的 技术 
公司 都 在 页 献 者 他 们 的 智慧 。 我 们 搜索 微服 务 架 构 的 实施 方案 时 会 友 
现 ， 几 乎 大 部 分 的 分 享 主要 以 理论 或 是 一 个 粗 轮廓 框架 为 主 ， 整 合 了 来 
目 不 同 公司 或 组 织 的 诸多 开源 框架 ， 并 加 入 针对 自身 业务 的 一 些 优化 ， 
所 以 找 不 到 一 个 完全 相同 的 架构 方案 。 

前 面 我 们 介绍 了 一 些 关 于 微服 务 的 理念 以 及 特性 ， 分 析 了 实施 微服 
务 的 优点 和 缺点 ， 而 这 些 缺 点 通 帝 束 是 这 些 框架 出 现 的 源头 ， 大 家 都 是 
为 了 解决 或 弥补 业务 拆 分 后 所 引出 的 诸多 问题 来 设计 出 这 些 解决 方案 。 
而 当 我 们 作为 一 个 新 手 ， 准 备 实施 微服 务 染 构 时 ， 为 了 避免 躁 前 华 们 踩 
过 的 坑 ， 我 们 不 得 不 在 这 些 核心 问题 上 做 出 选择 ， 而 选择 又 是 如 此 之 
I 
实验 精力 。 

Spring Cloud 的 出 现 ， 可 以 说 是 对 微服 务 架 构 的 巨大 文 持 和 强 有 力 的 
技术 后 盾 。 它 不 像 我 们 之 前 所 列举 的 框 染 那 样 ， 只 是 解决 微服 务 中 的 茶 
一 个 问题 ， 而 是 一 个 解决 微服 务 染 构 实 施 的 综合 性 解决 框架 ， 它 整合 
诸多 被 广泛 实践 和 证 明 过 的 框架 作为 实施 的 基础 部 件 ， 久 在 该 体系 基础 
上 创建 了 一 些 非 第 优秀 的 边缘 组 件 。 

打 个 不 太 恰 当 的 比喻 : 我 们 目 己 对 各 个 问题 选择 框架 来 实施 微服 务 
架构 就 像 在 DIY 电 脑 一 样 ， 我 们 对 各 环节 的 选择 自由 度 很 高 ， 但 是 最 终 


























结果 很 有 可 能 因为 一 条 内 存 质量 不 行驶 点 不 亮 了 ， 总 是 让 人 不 怎么 放 
心 。 当 然 ， 如 果 你 是 一 名 高 手 ， 这 些 目 然 都 不 是 问题 ， 然 而 千 军 易 得 、 
民 将 难 求 。 而 使 用 Spring “Cloud 来 实施 就 像 直接 购买 品牌 机 一 样 ， 在 
Spring 社区 的 整合 之 下 ， 做 了 大 量 的 兼容 性 测试 ， 保 证 了 其 拥有 更 好 的 
稳定 性 ， 如 果 要 在 Spring Cloud 架 构 下 使 用 非 原 闭 组 件 时 ， 束 需要 对 其 
基础 有 足够 的 了 解 。 

Spring Cloud 也 许 对 很 多 已 经 实施 微服 务 并 目 成 体系 的 团队 不 具备 足 
够 的 吸引 力 ， 但 是 对 于 还 未 实施 微服 务 或 是 未 成 体系 的 团队 ， 这 必 将 是 
一 个 非常 有 吸引 力 的 框架 选择 。 不 论 其 项 目的 发 展 目 标 ， 还 是 Spring 的 
强大 背景 ， 亦 或 其 极 高 的 社区 活跃 度 ， 都 是 未 来 企业 架构 师 必 须 了 解 和 
接触 的 重要 框架 ， 有 一 天 成 为 微服 务 染 构 的 标准 解决 方案 也 并 非 不 可 


全 已 
月 上。 

















Spring Cloud 人 简介 


Spring Cloud 是 一 个 基于 Spring Boot 实 现 的 微服 务 架 构 开 发 工具 。 它 
为 微服 务 架 构 中 涉及 的 配置 管理 、 服 务 治理 、 断 路 器 、 智 能 路 由 、 微 代 
理 、 控 制 总 线 、 全 局 锁 、 决 策 竞 选 、 分 布 式 会 话 和 集群 状态 管理 等 操作 
提供 了 一 种 简单 的 开发 方式 。 

Spring Cloud 包 含 了 多 个 子 项 目 〈 针 对 分 布 式 系统 中 涉及 的 多 个 不 同 
开源 产品 ， 还 可 能 会 新 增 ) ， 如 下 所 述 。 

eSpring Cloud Config: 配置 管理 工具 ， 文 持 使 用 Git 存 储 配置 内 容 ， 
可 以 使 用 它 实 现 应 用 配置 的 外 部 化 存储 ， 并 文 持 客户 端 配置 信息 刷新 、 
加 密 /解密 配置 内 容 等 。 

eSpring Cloud Netflix: 核心 组 件 ， 对 多 个 Netflix OSS 开 源 套件 进行 
整合 。 

加 Eureka: 服务 治理 组 件 ， 包 含 服 务 注册 中 心 、 服 务 注 册 与 发 现 机 制 
I 实现 。 

Hystrix: 容错 管理 组 件 ， 实 现 断 路 器 模式 ， 帮 助 服务 依赖 中 出 现 的 
延迟 和 为 故障 提供 强大 的 容错 能 力 。 

Ribbon: 客户 端 负载 均衡 的 服务 调用 组 件 。 

四 Feign: 基于 Ribbon 和 Hystrix 的 声明 式 服务 调用 组 件 。 

四 Zuul: 网 关 组 件 ， 提 供 智能 路 由 、 访 问 过 滤 等 功能 。 

加 Archaius: 外 部 化 配置 组 件 。 

eSpring Cloud Bus: 事件 、 消 息 总 线 ， 用 于 传播 集群 中 的 状态 变化 
或 事件 ， 以 触发 后 续 的 处 理 ， 比 如 用 来 动态 刷新 配置 等 。 

eSpring Cloud Cluster: 针对 ZooKeeper、Redis、Hazelcast、Consul 的 
选举 算法 和 通用 状态 模式 的 实现 。 

eSpring Cloud Cloudfoundry: 与 Pivotal Cloudfoundry 的 整合 支持 。 

eSpring Cloud Consul: 服务 发 现 与 配置 管理 工具 。 

eSpring Cloud Stream: 通过 Redis、Rabbit 或 者 Kafka 实 现 的 消费 微服 
务 ， 可 以 通过 简单 的 声明 式 模 型 来 发 送 和 接收 消息 。 

eSpring Cloud AWS: 用 于 简化 整合 Amazon Web Service 的 组 件 。 

eSpring Cloud Security: 安全 工具 包 ， 提 供 在 Zuul 代 理 中 对 OAuth2 客 
户 端 请 求 的 中 继 器 。 

eSpring Cloud Sleuth:Spring Cloud 应 用 的 分 布 式 跟踪 实现 ， 可 以 完美 
整合 Zipkin。 

eSpring Cloud ZooKeeper: 基于 ZooKeeper 的 服务 发 现 与 配置 管理 组 
人 





eSpring Cloud Starters:Spring Cloud 的 基础 组 件 ， 它 是 基于 Spring 
Boot 风 格 项 目的 基础 依赖 模块 。 

eSpring Cloud CLI: 用 于 在 Groovy 中 快速 创建 Spring Cloud 应 用 的 
Spring Boot CLI 插 件 。 

@ 


ee 


书 将 对 其 中 一 些 较为 党 用 的 组 件 进行 介绍 、 分 析 ， 并 演示 其 使 用 


\ 


方法 


版 本 说 明 


当 我 们 通过 搜索 引擎 查找 一 些 Spring Cloud 的 文章 或 示例 时 ， 往 往 可 
以 在 依赖 中 看 到 很 多 不 同 的 版 本 名 字 ， 比 如 Angel.SR6、Brixton.SR5 
等 ， 为 什么 Spring Cloud 没 有 像 其 他 Spring 的 项 目 使 用 类 似 1.x.x 的 版 本 命 
名 规则 呢 ? 这些 版 本 之 间 又 有 什么 区 别 呢 ? 在 学 习 之 初 ， 非 常 有 必要 弄 
清楚 这 些 版 本 的 意义 和 内 容 ， 这 样 才能 在 我 们 使 用 Spring ” Cloud 时 ， 指 
导 我 们 选择 更 为 合适 的 版 本 进行 架构 与 开发 。 

版 本 名 与 版 本 号 

由 于 Spring _ Cloud 不 像 Spring 社 区 其 他 一 些 项 目 那 样 相 对 独立 ， 它 是 
一 个 拥有 诸多 子 项 目的 大 型 综合 项 目 ， 可 以 说 是 对 微服 务 架 构 解决 方案 
的 综合 套件 组 合 ， 其 包含 的 各 个 子 项 目 也 都 独立 进行 着 内 容 更 新 与 迭 
代 ， 和 名目 都 维护 着 自己 的 发 布 版 本 号 。 因 此 每 一 个 Spring Cloud 的 版 本 
都 会 包含 多 个 不 同 版 本 的 子 项 目 ， 为 了 管理 每 个 版 本 的 子 项 目 清 单 ， 避 
免 $Spring ” Cloud 的 版 本 号 与 其 子 项 目的 版 本 号 相 泥 淆 ， 没 有 采用 版 本 瑟 
的 方式 ， 而 是 通过 命名 的 方式 。 

这 些 版 本 的 名 字 采 用 了 伦敦 地 铁 站 的 名 字 ， 根 据 字 母 表 的 顺序 来 对 
应 版 本 时 间 顺 序 ， 比 如 最 早 的 Release 版 本 为 Angel， 第 二 个 Release 版 本 
为 Brixton..….. 

经 过 上 面 的 解释 ， 不 难 猜 出 ， 之 前 所 提 到 的 Angel.SR6、Brixton.SR5 
中 的 SR6、SR5 就 是 版 本 号 了 。 

当 一 个 版 本 的 Spring Cloud 项 目的 发 布 内 容积 累 到 临界 点 或 者 一 个 严 
重 bug 解 决 可 用 后 ， 就 会 发 布 一 个 "service releases” 版 本 ， 人 简称 SRX 版 
本 ， 其 中 X 是 一 个 递增 的 数字 ， 所 以 Brixton.SR5 束 是 Brixton 的 第 5 个 
Release 版 本 。 

版 本 区 别 

下 面 列 出 的 是 开始 编写 此 书 时 各 版 本 的 版 本 构成 表 ， 我 们 可 以 快速 
查阅 当前 各 版 本 所 包含 的 子 项 目 ， 以 及 各 子 项 目的 版 本 号， 以 此 来 决定 
需要 选择 哪个 版 本 。 




















Component Angel.SR6 Brixton.SR5 
Camden.M1 Camden.BUILD-SNAPSHOT 

spring-cloud-aws 1.0.4.RELEASE 1.1.1.RELEASE 
1.1.1.RELEASE 1.1.2.BUILD-SNAPSHOT 

Spring-cloud-bus 1.0.3.RELEASE 1.1.1.RELEASE 
1.2.0.M1 1.2.0.BUILD-SNAPSHOT 


spring-cloud-cli 1.0.6.RELEASE 1.1.5.RELEASE 


1.2.0.M1 1.2.0.BUILD-SNAPSHOT 
spring-cloud-commons 1.0.5.RELEASE 1.1.1.RELEASE 

1.1.1.RELEASE 1.1.2.BUILD-SNAPSHOT 
spring-cloud-contract 


1.0.0.M2 1.0.0.BUILD-SNAPSHOT 

spring-cloud-config 1.0.4.RELEASE 1.1.3.RELEASE 
1.2.0.M1 1.2.0.BUILD-SNAPSHOT 

spring-cloud-netflix 1.0.7.RELEASE 1.1.5.RELEASE 
1.2.0.M1 1.2.0.BUILD-SNAPSHOT 

spring-cloud-security 1.0.3.RELEASE 1.1.2.RELEASE 
1.1.2.RELEASE 1.1.3.BUILD-SNAPSHOT 

spring-cloud-starters 1.0.6.RELEASE 

spring-cloud-cloudfoundry 1.0.0.RELEASE 
1.0.0.RELEASE 1.0.1.BUILD-SNAPSHOT 

spring-cloud-cluster 1.0.1.RELEASE 

spring-cloud-consul 1.0.2.RELEASE 
1.1.0.M1 1.1.0.BUILD-SNAPSHOT 

spring-cloud-sleuth 1.0.6.RELEASE 
1.0.6.RELEASE 1.0.7.BUILD-SNAPSHOT 

spring-cloud-stream 1.0.2.RELEASE 
Brooklyn.M1 Brooklyn.BUILD-SNAPSHOT 

spring-cloud-zookeeper 1.0.2.RELEASE 
1.0.2.RELEASE 1.0.3.BUILD-SNAPSHOT 

spring-boot 1.2.8.RELEASE 1.3.7.RELEASE 
1.4.0.RELEASE 1.4.0.RELEASE 

spring-cloud-task 1.0.2.RELEASE 


1.0.2.RELEASE 1.0.3.BUILD-SNAPSHOT 

不 难看 出 ， 最 初 的 Angel 版 本 相对 来 说 拥有 的 子 项 目 较 少 ，Brixton、 
Camden 则 拥有 更 全 的 子 项 目 ， 所 以 能 提供 更 多 的 组 件 文 持 。Brixton 的 
发 布 子 项 目 更 为 稳定 ，Camden 则 更 为 前 瞻 。 

由 于 Brixton 版 本 包含 了 大 部 分 的 Spring Cloud 子 项 目 ， 并 且 均 为 
Release 版 本 ， 所 以 本 文 所 有 示例 以 及 讲解 内 容 的 编写 均 采 用 Brixton.SR5 
版 本 ， 基 于 Spring Boot 1.3.7 版 本 。 

注意 : 在 本 书 完成 时 ，Brixton 版 本 已 经 升级 到 SR7， 本 书 中 的 示例 
均 可 直接 使 用 Brixton.SR7 来 完成 ， 但 是 在 使 用 Brixton 版 本 的 时 候 需 要 注 
意 Spring Boot 的 版 本 ， 必 须 使 用 1.3.x 版 本 ， 而 不 能 使 用 1.4.x 版 本 ， 人 否则 
会 出 现 各 种 问题 。 知 一 定 要 使 用 Spring ”1.4.x 版 本 的 话 ， 必 须 将 Spring 


Cloud 版 本 升级 到 Camden 版 本 ， 目 前 Camden 已 经 发 布 Release 版 本 ， 所 
以 可 以 放心 使 用 ， 最 新 版 本 为 Camden.SR3。 另 外 ，Camden 版 本 虽然 可 
以 兼容 Brixton 版 本 中 的 各 种 实现 方法 ， 但 是 在 升级 后 读者 会 发 现 有 一 些 
方法 已 经 被 标 注 为 过 期 ， 对 于 这 些 过 期 的 使 用 方法 ， 笔 者 后 续 会 在 博客 
中 逐个 编写 博文 来 说 明 这 些 更 新 内 容 。 所 以 ， 有 兴趣 的 读者 可 以 关注 我 
的 博客 (http://blog.didispace.com) ， 来 持续 获取 Spring Cloud 的 一 些 最 
新 动态 。 


第 2 章 做 服务 构建 Spring Boot 


在 展开 Spring Cloud 的 微服 务 架 构 部 署 之 前 ， 我 们 先 通 过 本 章 的 内 容 
来 了 解 一 下 用 于 构建 微服 务 的 基础 框架 一 Spring Boot。 对 于 Spring Boot 
己 经 有 深入 了 解 的 读者 可 以 直接 跳 过 本 章 ， 进 入 后 续 章 节 学 习 Spring 
Cloud 各 个 组 件 的 使 用 。 

如 果 对 于 Spring Boot 还 不 了 解 的 话 ， 建 议 先 读 完 本 章 内 容 之 后 再 继 
续 学 习 后 续 关 于 Spring ”Cloud 的 内 容 。 由 于 Spring “Cloud 的 构建 基于 
Spring Boot 实 现 ， 在 后 续 的 示例 中 我 们 将 大 量 使 用 Spring Boot 来 构建 微 
服务 架构 中 的 基础 设施 以 及 一 些 试验 中 使 用 的 微服 务 。 为 了 能 够 辅助 后 
续 内 容 的 介绍 ， 确 保 读 者 有 一 定 的 Spring ” Boot 基础 ， 在 这 里 先 对 Spring 
Boot 做 一 个 简单 的 介绍 ， 以 保证 读者 能 够 有 一 定 的 基础 去 理解 后 续 介绍 
的 内 容 并 顺利 完成 后 续 的 一 些 示例 试验 。 

在 这 里 介绍 Spring Boot 的 目的 除了 它 是 Spring Cloud 的 基础 之 外 ， 也 
由 于 其 自身 的 各 项 优点 ， 如 自动 化 配置 、 快 速 开 有 发、 轻松 部 署 等 ， 非 常 
适合 用 作 微 服务 架构 中 各 项 具体 微服 务 的 开发 框架 。 所 以 我 们 强烈 推荐 
使 用 Spring ”Boot 来 构建 微服 务 ， 它 不 仅 可 以 帮助 我 们 快速 地 构建 微服 
务 ， 还 可 以 轻松 简单 地 整合 Spring ” Cloud 实现 系统 服务 化 ， 而 如 果 使 用 
了 传统 的 Spring 构 建 方式 的 话 ， 在 整合 过 程 中 我 们 还 需要 做 更 多 的 依赖 
管理 工作 才能 让 它们 完好 地 运行 起 来 。 

在 本 章 中 我 们 将 介绍 下 面 这 些 与 后 续 介 绍 有 密切 联系 的 内 容 : 

e 如 何 构建 Spring Boot 项 目 

e 如 何 实现 RESTful API 接 口 

e 如 何 实现 多 环境 的 Spring Boot 应 用 配置 

e 深 入 理解 Spring Boot 配 置 的 启动 机 制 

eSpring Boot 应 用 的 监控 与 管理 

更 多 关于 Spring Boot 的 使 用 细节 ， 该 者 可 以 参阅 Spring Boot 的 官方 
文档 或 是 其 他 资料 来 进一步 学 习 。 








框 如 入 何 介 


对 于 很 多 Spring 框架 的 初学 者 来 说 ， 经 钟 会 因为 其 党 杂 的 配置 文件 而 
却步 。 而 对 于 很 多 老手 来 说 ， 每 次 新 构建 项 目 总 是 会 重复 复制 粘贴 一 些 
差不多 的 配置 文件 这 样 枯 燥 乏 味 的 事 。 作 为 一 名 优秀 的 程序 员 或 架构 
师 ， 我 们 总 会 想 尽 办 法 来 避免 这 样 的 重复 劳动 ， 比 如 ， 通 过 Maven 等 构 
建 工 具 来 创建 针对 不 同 场 景 的 脚手架 工程 ， 在 需要 新 建 项 目 时 通过 这 些 
脚手架 来 初始 化 我 们 自 定义 的 标准 工程 ， 并 根据 需要 做 一 些 简单 修改 以 
达到 简化 原 有 配置 过 程 的 效果 。 这 样 的 做 法 虽然 减少 了 工作 量 ， 但 是 这 
些 配置 依然 大 量 散 布 在 我 们 的 工程 中 ， 大 部 分 情况 下 我 们 并 不 会 去 修改 
这 些 内 容 ， 但 为 什么 还 要 反复 出 现在 我 们 的 工程 中 呢 ? 实在 有 些 碍 眼 ! 

Spring Boot 的 出 现 可 以 有 效 改善 这 类 问题 ，Spring Boot 的 宗 则 并 非 
要 重 写 Spring 或 是 殖 代 Spring， 而 是 希望 通过 设计 大 量 的 目 动 化 配置 等 
方式 来 简化 Spring 原 有 样板 化 的 配置 ， 使 得 开发 者 可 以 快速 构建 应 用 。 

除了 解决 配置 问题 之 外 ，Spring Boot 还 通过 一 系列 Starter POMs 的 定 
义 ， 让 我 们 整合 各 项 功能 的 时 候 ， 不 需要 在 Maven 的 pom.xml 中 维护 那 
些 错综复杂 的 依赖 和 关系， 而 是 通过 类 似 模块 化 的 Starter 模 块 定 义 来 引 
用 ， 使 得 依赖 管理 工作 变 得 更 为 简单 。 

在 如 今 容器 化 大 行 其 道 的 时 代 ，Spring Boot 除 了 可 以 很 好 融入 
Docker 之 外 ， 其 自身 就 文 持 肉 入 式 的 Tomcat、Jetty 等 容器 。 所 以 ， 通 
过 Spring Boot 构建 的 应 用 不 再 需要 安装 Tomcat， 将 应 用 打包 成 war， 再 
部 署 到 Tomcat 这 样 复杂 的 构建 与 部 署 动作 ， 只 需 将 Spring Boot 应 用 打 成 
jar 包 ， 并 通过 java-jar 命 令 直 接 运 行 就 能 启动 一 个 标准 化 的 Web 应 用 ， 这 
使 得 Spring Boot 应 用 变 得 非常 轻便 。 

Spring Boot 对 于 构建 、 部 署 等 做 了 这 么 多 的 优化 ， 目 然 不 能 少 了 对 
开发 环节 的 优化 。 整 个 Spring Boot 的 生态 系统 都 使 用 到 了 Groovy， 很 目 
然 的 ， 我 们 完全 可 以 通过 使 用 Gradle 和 Groovy 来 开发 Spring Boot 应 用 ， 
比如 下 面 短 短 的 不 足 100 个 字符 的 代码 ， 通 过 编译 打包 ， 使 用 java -jar 命 
令 就 能 启动 一 个 返回 “hello” 的 RESTful API。 

(DRestController 

class App { 

@RequestMapping ("/") 

String home () { 

"hello" 

} 

} 






































说 了 这 么 多 Spring ” ”Boot 市 来 的 颠 履 性 框架 特性 ， 下 面 我 们 就 通过 后 
续 内 容 来 体验 一 下 使 用 Spring Boot 构 建 微服 务 的 过 程 ， 以 对 Spring Boot 
有 一 个 直观 的 感受 。 
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在 本 节 中 ， 我 们 将 逐步 指引 读者 创建 一 个 Spring ”Boot 的 基础 项 目 ， 
并 且 实 现 一 个 简单 的 RESTful API， 通 过 这 个 例子 对 Spring Boot 有 一 个 
初步 的 了 解 ， 并 体验 其 结构 简单 、 开 发 迅速 的 特性 。 


项 目 构 建 与 解析 


系统 及 工具 版 本 要 求 

eJava 7 及 以 上 版 本 

eSpring Framework 4.2.7 及 以 上 版 本 

eMaven 3.2 及 以 上 版 本 /Gradle 1.12 及 以 上 版 本 

本 书 内 容 均 采用 Java 1.8.0_73、Spring Boot 1.3.7 调 试 通过 。 

构建 Maven 项 目 

1. 通 过 官方 的 Spring Initializr 工 具 来 产生 基础 项 目 。 

2. 访 问 http://start.spring.io/， 如 下 图 所 示 ， 该 页 面 提供 了 以 Maven 或 
Gradle 构 建 Spring Boot 项 目的 功能 。 

3. 选 择 构建 工具 Maven Project、Spring Boot 版 本 选择 1.3.7， 填 写 
Group 和 Artifact 信 息 ， 在 Search for dependencies 中 可 以 搜索 需要 的 其 他 
依赖 包 ， 这 里 我 们 要 实现 RESTful API， 所 以 可 以 添加 Web 依 赖 。 

4. 单 击 Generate Project 按 钮 下 载 项 目 压 缩 包 。 

5. 解 压 项 目 包 ， 并 用 IDE 以 Maven 项 目 导 入 ， 以 Intellij IDEA 14 为 
例 。 

6. 从 菜单 中 选择 File-->New-->Project from Existing Sources...。 

7. 选 择 解压 后 的 项 目 文件 来 ， 单 击 OK 按钮 。 
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8. 单 击 Import project from external model 并 选择 Maven， 一 直 单 击 Next 
按钮 。 

9. 若 你 的 环境 中 有 多 个 版 本 的 JDK， 选 择 Java SDK 的 时 候 请 选择 Java 
7 以 上 的 版 本 。 

工程 结构 解析 

在 完成 了 上 面 的 步骤 之 后 ， 我 们 就 创建 了 一 个 最 基础 的 Spring Boot 
| 和 





如 上 图 所 示 ，Spring ” Boot 的 基础 结构 有 三 大 块 (具体 路 径 根 据 用 户 
生成 项 目 时 填写 的 Group 和 Artifact 有 所 差异 ) 。 

esrc/main/java: 主 程序 入 口 HelloApplication， 可 以 通过 直接 运行 该 
类 来 启动 Spring Boot 应 用 。 








esrc/main/resources: 配置 目录 ， 该 目录 用 来 存放 应 用 的 一 些 配 置信 
轧 ， 比 如 应 用 名 、 服 务 端口 、 数 据 库 链 接 等 。 由 于 我 们 引入 了 Web 模 
块 ， 因 此 产生 了 static 目 录 与 templates 目 录 ， 前 者 用 于 存放 静态 资源 ， 如 
图 片 、CSS、JavaScript 等 ， 后 者 用 于 存放 Web 页 面 的 模板 文件 ， 这 里 我 
们 主要 演示 提供 RESTful API， 所 以 这 两 个 目录 并 不 会 用 到 。 

esrc/test/: 单元 测试 目录 ， 生 成 的 HelloApplicationTests 通 过 JUnit 4 实 
现 ， 可 以 直接 用 运行 Spring Boot 应 用 的 测试 。 后 文中 ， 我 们 会 演示 如 何 
在 该 类 中 测试 RESTful API。 

Maven 配 置 分 析 

打开 当前 工程 下 的 pom.xml 文件 ， 看 看 生成 的 项 目 都 引入 了 哪些 依 
赖 来 构建 Spring Boot 工 程 ， 内 容 大 致 如 下 所 示 。 

<? Xml version="1.0" encoding="UTF-8"? > 

<project xmlns="http://maven.apache.org/POM/4.0.0" 
xmlns:xsi="http:/www.w3.0rg/2001/XMLSchema-instance" 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0http://maven.apache 
4.0.0.xsd"> 

<modelVersion>4.0.0</modelVersion> 

<groupId>com.didispace</groupId> 

<artifactId>spring-boot-hello</artifactId> 

<version>0.0.1-SNAPSHOT</version> 

<packaging>jar</packaging> 

<name>spring-boot-hello</name> 

<description>Demo project for Spring Boot</description> 

<parent> 

<groupId>org.Springframework.boot</groupId> 

<artifactId>spring-boot-starter-parent</artifactId> 

<version>1.3.7.RELEASE</version> 

<relativePath/> <!--lookup parent from repository--> 

</parent> 

<properties> 

<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> 

<project.reporting.outputEncoding>UTF- 
8</project.reporting.outputEncoding> 

<java.version>1.8</java.version> 

</properties> 

<dependencies> 

<dependency> 











<groupId>org.Springframework.boot</groupId> 

<artifactId>spring-boot-starter-web</artifactId> 

</dependency> 

<dependency> 

<groupId>org.Springframework.boot</groupId> 

<artifactId>spring-boot-starter-test</artifactId> 

<scope>test</scope> 

</dependency> 

</dependencies> 

<build> 

<plugins> 

<plugin> 

<groupId>org.Springframework.boot</groupId> 

<artifactId>spring-boot-maven-plugin</artifactId> 

</plugin> 

</plugins> 

</build> 

</project> 

在 基础 信息 部 分 ，groupId 和 artifactId 对 应 生成 项 目 时 页 面 上 输入 的 
内 容 。 男 外 ， 我 们 还 可 以 注意 到 ， 打 包 形 式 为 jar: 
<packaging>jar</packaging>， 正 如 我 们 之 前 所 介绍 的 ，Spring Boot 默 认 
将 该 Web 应 用 打包 为 jar 的 形式 ， 而 非 war 的 形式 ， 因 为 默认 的 Web 模 块 
依赖 会 包含 供 入 式 的 Tomcat， 这 样 使 得 我 们 的 应 用 jar 目 吴 就 具备 了 提供 
Web 服 务 的 能 力 ， 后 续 我 们 会 演示 如 何 启 动 它 。 

父 项 目 parent 配 置 指定 为 spring-boot-starter-parent 的 1.3.7 版 本 ， 该 父 
项 目 中 定义 了 Spring Boot 版 本 的 基础 依赖 以 及 一 些 默 认 配置 内 容 ， 比 
如 ， 配 置 文件 application.properties 的 位 置 等 。 

在 项 目 依赖 dependencies 配 置 中 ， 包 含 了 下 面 两 项 。 

espring-boot-starter-web: 全 栈 Web 开 发 模块 ， 包 含 嵌 入 式 Tomcat、 
Spring MYVC。 

espring-boot-starter-test: 通用 测试 模块 ， 包 含 JUnit、Hamcrest、 
Mockito 。 

这 里 所 引用 的 web 和 test 模 块 ， 在 Spring Boot 生 态 中 被 称 为 Starter 
POMs。Starter POMs 是 一 系列 轻便 的 依赖 包 ， 是 一 套 一 站 式 的 Spring 相 
关 技 术 的 解决 方案 。 开 发 者 在 使 用 和 整合 模块 时 ， 不 必 再 去 搜寻 样 例 代 
码 中 的 依赖 配置 来 复制 使 用 ， 只 需要 引入 对 应 的 模块 包 即 可 。 比 如 ， 开 
发 Web 应 用 的 时 候 ， 就 引入 spring-boot-starter-web， 和 希望 应 用 具备 访问 

















数据 库 能 力 的 时 候 ， 那 就 再 引入 ”spring-boot-starter-jdbc 或 是 更 好 用 的 
spring-boot-starter-data-jpa。 在 使 用 Spring Boot 构 建 应 用 的 时 候 ， 各 项 功 
能 模块 的 整合 不 再 像 传统 Spring 应 用 的 开发 方式 那样 ， 需 要 在 pom.xml 
中 做 大 量 的 依赖 配置 ， 而 是 通过 使 用 Starter POMs 定 义 的 依赖 包 ， 使 得 
功能 模块 整合 变 得 非常 轻巧 ， 易 于 理解 与 使 用 。 

Spring Boot 的 Starter POMs 采 用 spring-boot-starter-* 的 命名 方式 ，* 代 
表 一 个 特别 的 应 用 功能 模块 ， 比 如 这 里 的 web、test。Spring Boot 工 程 本 
身 的 结构 非常 简单 ， 大 量 的 学 习 要 点 还 是 将 来 在 对 这 些 Starter POMs 的 
使 用 之 上 。 在 本 书 中 ， 由 于 主要 讲述 Spring ” Cloud 的 微服 务 组 件 内 容 ， 
因此 对 各 个 Spring Boot 的 模块 内 容 不 做 详尽 讲解 。 对 于 初学 者 来 说 ， 我 
们 也 不 必 一 次 性 地 将 所 有 模块 的 详细 用 法 都 掌握 牢固 ， 只 需 了 解 每 个 模 
块 能 做 什么 即 可 。 对 于 本 书 所 使 用 的 Spring Boot 1.3.7 版 本 的 所 有 Starter 
POMSs 的 功能 索引 可 以 参见 附录 A， 可 以 根据 目 身 的 需要 来 查询 能 够 文 
持 的 模块 ， 再 去 搜索 这 个 模块 的 使 用 方法 来 实现 我 们 的 需求 。 

最 后 ， 项 目 构建 的 bpuild 部 分 ， 引 入 了 Spring Boot 的 Maven 插 件 ， 该 插 
件 非常 实用 ， 可 以 帮助 我 们 方便 地 启 停 应 用 ， 这 样 在 开发 时 就 不 用 每 次 
去 找 主 类 或 是 打包 成 jar 来 运行 微服 务 ， 只 需要 通过 mvn spring-boot:run 
命令 就 可 以 快速 启动 Spring Boot 应 用 。 




















实现 RESTful API 


在 Spring Boot 中 创建 一 个 RESTful API 的 实现 代码 同 Spring MVC 应 用 
一 样 ， 只 是 不 需要 像 Spring MVC 那 样 完 做 很 多 配置 ， 而 是 像 下 面 这 样 直 
接 开 始 编 写 Controller 内 容 : 

e@ 新 建 package， 命 名 为 com.didispace.web， 可 根据 实际 的 构建 情况 修 
改 成 自己 的 路 径 。 

e 新 建 HelloController 类 ， 内 容 如 下 所 示 。 

(DRestController 

public class HelloController { 

} 

@RequestMapping ("/hello") 

public String index () { 

return "Hello World"; 





} 

e 启 动 该 应 用 ， 通 过 浏览 器 访问 http://localhost:8080/hello， 我 们 可 以 
看 到 返回 了 预期 结果 : Hello World。 

启动 Spring Boot 应 用 





启动 Spring Boot 应 用 的 方式 有 很 多 种 : 
e 作 为 一 个 Java 应 用 程序 ， 可 以 直接 通过 运行 拥有 main 函 数 的 类 来 启 


动 。 

e 在 Maven 配 置 中 ， 之 前 提 到 了 spring-boot 插 件 ， 可 以 使 用 它 来 启 
动 ， 比 如 执行 mvn spring-boot:run 命 令 ， 或 是 直接 单 击 IDE 中 对 Maven 插 
件 的 工具 ， 例 如 IntelliJ 中 的 支持 : 


















e 在 服务 器 上 部 署 运行 时 ， 通 党 先 使 用 mvn ” install 将 应 用 打包 成 jar 
包 ， 再 通过 java-jar xxx.jar 来 启动 应 用 。 

编写 单元 测试 

功能 实现 之 后 ， 我 们 要 养 成 随手 写 配套 单元 测试 的 习惯 ， 这 在 微服 
务 架构 中 尤为 重要 。 通 常 ， 我 们 实施 微服 务 架 构 的 时 候 ， 已 经 实现 了 前 
后 端 分 离 的 项 目 与 架构 部 署 。 那 么 在 实现 后 端 服务 的 时 候 ， 单 元 测试 是 
在 开发 过 程 中 用 来 验证 代码 正确 性 非常 好 的 手段 ， 并 且 这 些 单 元 测试 将 
会 很 好 地 文 持 我 们 未 来 可 能 会 进行 的 重 构 。 

在 Spring ” Boot 中 实现 单元 测试 同样 非常 方便 ， 下 面 我 们 打开 src/test/ 
下 的 测试 入 口 com.didispace.HelloApplicationTests 类 ， 编 写 一 个 简单 的 
单元 测试 来 模拟 HTTP 请 求 ， 测 试 之 前 实现 的 /hello 接 口 ， 该 接口 应 返回 
Hello World 字 符 串 。 

具体 代码 实现 如 下 所 示 。 

@RunWwith (SpringJUnit4ClassRunner.class) 

@SpringApplicationConfiguration (classes=HelloApplication.class) 

@WebAppConfiguration 

public class HelloApplicationTests { 

private MockMvc mvc; 

@Before 

public void setUp 〈) throws Exception { 

mvc=MockMvcBuilders.standaloneSetup (new 
HelloController () ) .build (); 
| 
(@Test 
public void hello () throws Exception { 











mvc.perform (MockMvcRequestBuilders.get ("/hello") .accept 〈Medis 
.andExpect (status () .isOk () ) 

.andExpect (content () .string (equalTo ("Hello World") ) ) ; 

} 


} 

代码 解析 如 下 。 

eQ@RunWith (SpringJUnit4ClassRunner.class) : 引入 Spring 对 JUnit4 
的 文 持 。 

eOSpringApplicationConfiguration (classes=HelloApplication.class) : 
指定 Spring Boot 的 启动 类 。 

e(@WebAppConfiguration: 开启 Web 应 用 的 配置 ， 用 于 模拟 
ServletContext。 

eMockMvc 对 象 : 用 于 模拟 调用 Controller 的 接口 发 起 请 求 ， 在 @Test 
定义 的 hello 测 试用 例 中 ，perform 函 数 执行 一 次 请 求 调用 ，accept 用 于 执 
行 接收 的 数据 类 型 ，andExpect 用 于 判断 接口 返回 的 期 望 值 。 

e(@Before:JUnit 中 定义 在 测试 用 例 @Test 内 容 执行 前 预 加 载 的 内 容 ， 
这 里 用 来 初始 化 对 HelloController 的 模拟 。 

注意 引入 下 面 的 静态 引用 ， 让 status、content、equalTo 函 数 可 用 : 


import static org.hamcrest.Matchers.equalIo; 


Import static 
org.springframework.test.web.servlet.result.MockMvcResultMatchers.content 
import static 


org.springframework.test.web.servlet.result.Mock MvcResultMatchers.status; 

快速 入 门 总 结 

在 本 市 中 ， 我 们 通过 Spring 官 方 的 项 目 构建 工具 Spring Initializr 生 成 
了 一 个 Spring Boot 的 基础 项 目 ， 并 详细 介绍 了 该 基础 项 目的 依赖 结构 以 
及 Maven 的 spring-boot 插 件 ， 接 着 在 该 项 目 中 实现 一 个 输出 “Hello 
World” 的 RESTful 接 口 以 及 针对 该 接口 的 单元 测试 用 例 ， 完 成 了 一 个 虽 
然 镜 单 ， 但 涵盖 了 项 目 构 建 、 服 务 开发 、 单 元 测试 的 全 套 开 发 内 容 。 由 
于 我 们 在 后 续 使 用 Spring Cloud 的 时 候 会 构建 多 个 Spring Boot 的 项 目 来 
实现 微服 务 架 构 中 的 基础 设施 以 及 微服 务 应 用 ， 所 以 通过 本 市 的 学 习 ， 
我 们 已 经 具备 了 通过 使 用 Spring ”Boot 来 构建 简单 微服 务 项 目的 基本 能 


2 
在 下 一 节 中 ， 我 们 将 对 后 续 在 Spring Cloud 组 件 使 用 过 程 中 会 涉及 的 
配置 内 容 做 一 些 介绍 和 人 解释。 











本 兽 EE: 解 


在 上 一 节 中 ， 我 们 轻松 地 实现 了 一 个 简单 的 RESTful API 应 用 ， 体 验 
了 Spring Boot 的 诸多 优点 。 我 们 用 非常 少 的 代码 残 成 功 实现 了 一 个 Web 
应 用 ， 这 是 传统 Spring 应 用 无 法 办 到 的 。 虽 然 在 实现 Controller 时 用 到 的 
代码 是 一 样 的 ， 但 是 在 配置 方面 ， 相 信 大 家 也 注意 到 了 ， 在 上 面 的 例子 
中 ， 除 了 Maven 的 配置 之 外 ， 没 有 引入 任何 其 他 配置 。 

这 就 是 之 前 我 们 提 到 的 ，Spring ”Boot 针 对 常用 的 开发 场景 提供 了 一 
系列 自动 化 配置 来 减少 原本 复杂 而 又 几乎 很 少 改动 的 模板 化 配置 内 容 。 
但 是 ， 我 们 还 是 需要 了 解 如 何在 Spring Boot 中 修改 这 些 自动 化 的 配置 内 
容 ， 以 应 对 一 些 特殊 的 场景 需求 ， 比 如 ， 我 们 在 同一 台 主 机 上 需要 启动 
多 个 基于 Spring Boot 的 Web 应 用 ， 知 不 为 每 个 应 用 指定 特别 的 端口 号 ， 
那么 默认 的 8080 端 口 必 将 导致 冲突 。 

后 续 我 们 在 使 用 Spring Cloud 的 各 个 组 件 的 时 候 ， 其 实 有 大 量 的 工作 
都 会 是 针对 配置 文件 的 。 所 以 我 们 有 必要 深入 了 解 一 些 关 于 Spring Boot 
中 的 配置 文件 的 知识 ， 比 如 配置 方式 、 如 何 实现 多 环境 配置 、 配 置信 息 
的 加 载 顺 序 等 。 


配置 文件 


在 快速 入 门 示例 中 ， 我 们 介绍 Spring Boot 的 工程 结构 时 ， 提 到 过 
src/main/resources 目 录 是 Spring Boot 的 配置 目录 ， 所 以 当 要 为 应 用 创建 
个 性 化 配置 时 ， 应 在 该 目录 下 进行 。 

Spring Boot 的 默认 配置 文件 位 置 为 
src/main/resources/application.properties。 关 于 Spring ”Boot 应 用 的 配置 内 
容 都 可 以 集中 在 该 文件 中 ， 根 据 我 们 引入 的 不 同 Starter 模 块 ， 可 以 在 这 
里 定义 容器 端口 号 、 数 据 库 连接 信息 、 日 志 级 别 等 各 种 配置 信息 。 比 
如 ， 我 们 需要 上 自 定义 Web 模 块 的 服务 端口 号 ， 可 以 在 
application.properties 中 添加 server.port=8888 来 指定 服务 端口 为 8888， 也 
可 以 通过 spring.application.name=hello 来 指定 应 用 名 (该 名 字 在 后 续 
Spring Cloud 中 会 被 注册 为 服务 名 ) 。 

Spring ”Boot 的 配置 文件 除了 可 以 使 用 传统 的 properties 文 件 之 外 ， 还 
文 持 现在 被 广泛 推荐 使 用 的 YAML 文 件 。 

YAML (英语 发 首 为 /jemal/， 尾 音 类 似 camel 骆 弦 ) 是 一 个 可 读 性 
高 ， 用 来 表达 资料 序列 的 格式 。YAML 参 考 了 其 他 多 种 语言 ， 包 括 C 语 
































言 、Python、Perl， 并 从 XML、 电 子 邮 件 的 数据 格式 (RFC 2822) 中 获 
得 灵感 。Clark Evans 在 2001 年 首次 发 表 了 这 种 语言 ，Ingy d6t Net 与 Oren 
Ben-Kiki 也 是 这 种 语言 的 共同 设计 者 。 目 前 已 经 有 数 种 编程 语言 或 脚本 
语言 支持 (或 者 说 解析 〉 这 种 语言 。YAML 是 YAML Aint a Markup 
Language (YAML 不 是 一 种 标记 语言 ) 的 缩写 。 在 开发 这 种 语言 时 ， 
YAML 的 意思 其 实 是 : Yet Another Markup Language( 仍 是 一 种 标记 语 
言 ) ， 但 为 了 强调 这 种 语言 以 数据 作为 中 心 ， 而 不 是 以 标记 语言 为 重 
点 ， 而 用 反 向 缩 略 语 重 新 命名 。YAML 的 语法 和 其 他 高 阶 语言 类 似 ， 并 
且 可 以 简单 地 表达 清单 、 散 列表 、 标 量 等 形态 。 它 使 用 空白 符号 缩 排 和 
大 量 依赖 外 观 的 特色 ， 特 别 适 合用 来 表达 或 编辑 数据 结构 、 各 种 设 定 文 
档 、 文 件 大 纲 〈 例 如 ， 许 多 电子 邮件 标题 格式 和 YAML 非 常 接近 〉 。 尽 
管 它 比较 适合 表达 阶层 式 (hierarchical model) 的 数据 结构 ， 不 过 也 有 
精致 的 语法 可 以 表示 关联 性 (relational model) 的 资料 。 由 于 YAML 使 
用 空白 符号 和 分 行 来 分 隔 资 料 ， 使 得 它 特别 适合 
grep/Python/Perl/Ruby 操 作 。 其 让 人 最 容易 上 手 的 特色 是 巧妙 避 开 各 种 
封闭 符号 ， 如 引号 、 各 种 括号 等 ， 这 些 符号 在 虽 状 结构 时 会 变 得 复杂 而 
难以 辨认 。 

一 一 维基 百科 

YAML 采 用 的 配置 格式 不 像 properties 的 配置 那样 以 单纯 的 键 值 对 形 
式 来 表示 ， 而 是 以 类 似 大 网 的 缩 进 形式 来 表示 。 下 面 是 一 段 YAMI 配置 

environments: 

dev: 

url:http://dev.bar.com 

name: Developer Setup 

prod: 

url:http://foo.bar.com 

name: My Cool App 

与 其 等 价 的 properties 配 置 如 下 所 示 : 

environments.dev.url=http://dev.bar.com 

environments.dev.name=Developer Setup 

environments.prod.url=http://foo.bar.com 

environments.prod.name=My Cool App 

通过 YAML 的 配置 方式 我 们 可 以 看 到 ， 配 置信 息 利 用 阶梯 化 缩 进 的 
方式 ， 其 结构 更 为 清晰 易 恋 ， 同 时 配置 内 容 的 字符 量 也 得 到 显著 减少 。 
除 此 之 外 ，YAML 还 可 以 在 一 个 单个 文件 中 通过 使 用 spring.profiles 属 性 
来 定义 多 个 不 同 的 环境 配置 。 例 如 下 面 的 内 容 ， 在 指定 为 test 环 境 时 ， 

















server.port 将 使 用 8882 端 口 ， 而 在 prod 环 境 中 ，server.port 将 使 用 8883 端 
口 ， 如 果 没 有 指定 环 境 ， server.port 将 使 用 8881 端 口 。 

server: 

port: 8881 

spring: 

profiles: test 

server: 

port: 8882 

spring: 

profiles: prod 

server: 

port: 8883 

四 注意 YAML 目 前 还 有 一 些 不 足 ， 它 无 法 通过 @PropertySource 注 解 
来 加 载 配置 。 但 是 ， YAML 将 属 性 加 载 到 内 存 中 保存 的 时 候 是 有 序 的 ， 
所 以 当 配 置 文件 中 的 信息 需要 具备 顺序 含义 时 ，YAML 的 配置 方式 比 起 
properties 配 置 文件 更 有 优势 。 


Pz 参 类 














除了 可 以 在 Spring Boot 的 配置 文件 中 设置 各 个 Starter 模 块 中 预定 义 的 
配置 属性 ， 也 可 以 在 配置 文件 中 定义 一 些 我 们 需要 的 自 定 义 属性 。 比 如 
在 application.properties 中 添加 : 

book.name=SpringCloudInAction 

ey 
然后 ， 在 应 用 中 可 以 通过 @Value 注 解 来 加 载 这 些 自 定义 的 参数 ， 比 

0D: 

@Component 

public class Book { 

@Value ("${book.name}") 

private String name; 

@Value ("${book.author}") 

private String author; 

/省 略 getter 和 setter 


} 
@Value 注 解 加 载 属性 值 的 时 候 可 以 文 持 两 种 表达 式 来 进行 配置 ， 如 








下 所 示 。 

e 一 种 是 上 面 介 绍 的 PlaceHolder 方 式 ， 格 式 为 ${...}， 大 括号 内 为 
PlaceHolder 。 

e 男 一 种 是 使 用 SpEL 表 达 式 (Spring Expression Language) ， 格 式 为 
#{...}， 大 括号 内 为 SpEL 表 达 式 。 


参 类 


在 application.properties 中 的 各 个 参数 之 间 可 以 直接 通过 使 用 
PlaceHolder 的 方式 来 进行 引用 ， 束 像 下 面 的 设置 : 

book.name=SpringCloud 

book.author=ZhaiYongchao 

book.desc=${book.author} is writing《${fbook.name}》 

book.desc 参 数 引 用 了 上 文中 定义 的 book.name 和 book.author 属 性 ， 最 
后 该 属性 的 值 就 是 ZhaiYongchao is writing《SpringCloud》 。 


使 用 随机 炎 和 


在 一 些 特 殊 情 况 下 ， 我 们 希望 有 些 参 数 每 次 被 加 载 的 时 候 不 是 一 个 
固定 的 值 ， 比 如 密 铀 、 服 务 端口 等 。 在 Spring Boot 的 属性 配置 文件 中 ， 
可 以 通过 使 用 ${random} 配 置 来 产生 随机 的 int 值 、long 值 或 者 string 字 符 
串 ， 这 样 我 们 就 可 以 容易 地 通过 配置 随机 生成 属性 ， 而 不 是 在 程序 中 通 
过 编码 来 实现 这 些 逻 辑 。 

${random} 的 配置 方式 主要 有 以 下 儿 种 ， 读 者 可 作为 参考 使 用 。 

# 随机 字符 串 

com.didispace.blog.value=${random.value} 

# 随机 int 

com.didispace.blog.number=${random.int} 

# 随机 long 

com.didispace.blog.bignumber=${random.long} 

#10 以 内 的 随机 数 

com.didispace.blog,.test1=${random.int (10) } 

# 10 一 20 的 随机 数 

com.didispace.blog.test2=${random.int[10,20]} 

该 配置 方式 可 以 设置 应 用 端口 等 场景 ， 以 避免 在 本 地 调试 时 出 现 端 
口 冲 突 的 麻烦 。 





从 人 人 秆 佐 财 


口 2 


回顾 一 下 在 本 章 的 “快速 入 门 ? 小 节 中 ， 我 们 还 介绍 了 如 何 局 动 Spring 
Boot 应 用 ， 其 中 提 到 了 使 用 命令 java-jar 来 启动 的 方式 。 该 命令 除了 启 
动 应 用 之 外 ， 还 可 以 在 命令 行 中 指定 应 用 的 参数 ， 比 如 java-jar xxx.jar-- 
server.port=8888， 直 接 以 命令 行 的 方式 来 设置 server.port 属 性 ， 并 将 启动 
应 用 的 端口 设 为 8888。 

在 用 命令 行 方式 启动 Spring Boot 应 用 时 ， 连 续 的 两 个 减 写 -- 就 是 对 
application.properties 中 的 属性 值 进行 赋值 的 标识 。 所 以 ，java-jar 
XXX.jar--Sserver.port=8888 命 令 ， 等 价 于 在 application.properties 中 添加 属性 
Server.port=8888 。 

通过 命令 行 来 修改 属性 值 是 Spring ” Boot 非常 重要 的 一 个 特性 。 通 过 
此 特性 ， 理 论 上 已 经 使 得 应 用 的 属性 在 启动 前 是 可 变 的 ， 所 以 其 中 的 端 
口号 也 好 、 数 据 库 连 接 也 好 ， 都 是 可 以 在 应 用 启动 时 发 生 改 变 的 ， 而 不 
同 于 以 往 的 Spring 应 用 通过 Maven 的 Profile 在 编译 器 中 进行 不 同 环 境 的 构 
建 。Spring Boot 的 这 种 方式 ， 可 以 让 应 用 程序 的 打包 内 容 贯 穿 开 发 、 测 
试 以 及 线 上 部 署 ， 而 Maven 不 同 Profile 的 方案 为 每 个 环境 所 构建 的 包 ， 
其 内 容 本 质 上 是 不 同 的 。 但 是 ， 如 果 每 个 参数 都 需要 通过 命令 行 来 指 
定 ， 这 显然 也 不 是 一 个 好 的 方案 ， 所 以 下 面 我 们 看 看 如 何在 Spring Boot 
中 实现 多 环境 的 配置 。 


多 环境 配置 


我 们 在 开发 应 用 的 时 候 ， 通 党 同一 套 程 序 会 被 应 用 和 安装 到 几 个 不 
同 的 环境 中 ， 比 如 开发 、 测 试 、 生 产 等 。 其 中 每 个 环境 的 数据 库 地 址 、 
服务 器 端口 等 配置 都 不 同 ， 如 果 在 为 不 同 环境 打包 时 都 要 频繁 修改 配置 
文件 的 话 ， 那 必 将 是 个 非常 烦琐 且 容 易 发 生 错误 的 事 。 

对 于 多 环境 的 配置 ， 各 种 项 目 构 建 工具 或 是 框 染 的 基本 思路 是 一 致 
的 ， 通 过 配置 多 份 不 同 环境 的 配置 文件 ， 再 通过 打包 命令 指定 需要 打包 
Spring Boot 也 不 例外 ， 或 者 说 实现 起 来 更 加 

在 “Spring Boot 中 ， 多 环境 配置 的 文件 名 需要 满足 application- 
{profile}.properties 的 格式 ， 其 中 {profile} 对 应 你 的 环境 标识 ， 如 下 所 
示 。 

eapplication-dev.properties: 开发 环境 。 

eapplication-test.properties: 测试 环境 。 

eapplication-prod.properties: 生产 环境 。 














至 于 具体 哪个 配置 文件 会 被 加 载 ， 需 要 在 application.properties 文件 
中 通过 spring.profiles.active 属性 来 设置 ， 其 值 对 应 配置 文件 中 的 
{profile} 值 。 如 spring.profiles.active=test 束 会 加 载 application- 
test.properties 配 置 文件 内 容 。 

下 面 ， 以 不 同 环境 配置 不 同 的 服务 端口 为 例 ， 进 行 样 例 实验 。 

e 针 对 各 环境 新 建 不 同 的 配置 文件 application-dev.properties、 
application-test.properties、application-prod.properties 。 

e 在 这 三 个 文件 中 均 设 置 不 同 的 server.port 属 性 ， 例 如 ，dev 环 境 设置 
为 1111,test 环 境 设 置 为 2222,prod 环 境 设 置 为 3333。 

eapplication.properties 中 设置 Spring.profiles.active=dev， 意 为 默认 以 
dev 环 境 设置 。 

e 测 试 不 同 配置 的 加 载 。 

e 执 行 java-jar xxx.jar， 可 以 观察 到 服务 端口 被 设置 为 1111， 也 就 是 
默认 的 开发 环境 (dev) 。 

e@ 执 行 java-jar xxx.jar--spring.profiles.active=test， 可 以 观察 到 服务 端 
口 被 设置 为 2222， 也 就 是 测试 环境 的 配置 〈test) 。 

e@ 执 行 java-jar xxx.jar--spring.profiles.active=prod， 可 以 观察 到 服务 端 
口 被 设置 为 3333， 也 就 是 生产 环境 的 配置 (prod) 。 

按照 上 面 的 实验 ， 可 以 如 下 总 结 多 环境 的 配置 思路 ; 

e 在 application.properties 中 配置 通用 内 容 ， 并 设置 
Spring.profiles.active=dev， 以 开发 环境 为 默认 配置 。 

e 在 application-{profile}.properties 中 配置 各 个 环境 不 同 的 内 容 。 

e 通 过 命令 行 方式 去 激活 不 同 环境 的 配置 。 


顺 





在 上 面 的 例子 中 ， 我 们 将 Spring ”Boot 应 用 需要 的 配置 内 容 都 放 在 了 
项 目 工程 中 ， 已 经 能 够 通过 spring.profiles.active 或 是 通过 Maven 来 实现 
多 环境 的 文 持 。 但 是 ， 当 团队 逐渐 壮大 ， 分 工 越 来 越 细 致 之 后 ， 往 往 不 
需要 让 开发 人 员 知 道 测试 或 是 生产 环境 的 细节 ， 而 是 希望 由 每 个 环境 各 
自 的 负责 人 《〈QA 或 是 运 维 ) 来 集中 维护 这 些 信 息 。 那 么 如 果 还 是 以 这 
样 的 方式 存储 配置 内 容 ， 对 于 不 同 环境 配置 的 修改 就 不 得 不 去 获取 工程 
内 容 来 修改 这 些 配 置 内 容 ， 当 应 用 非常 多 的 时 候 就 变 得 非常 不 方便 。 同 
时 ， 配 置 内 容 对 开发 人 员 者 可见， 这 本 和 映 也 是 一 种 安全 隐患 。 对 此 ， 出 
现 了 很 多 将 配置 内 容 外 部 化 的 框架 和 工具 ， 后 续 将 要 介绍 的 Spring 
Cloud Config 就 是 其 中 之 一 ， 为 了 后 续 能 更 好 地 理解 Spring Cloud 
Config 的 加 载 机 制 ， 我 们 需要 对 Spring Boot 对 数据 文件 的 加 载 机 制 有 一 





























定 的 了 解 。 

为 了 能 够 更 合理 地 重 写 各 属性 的 值 ，Spring ”Boot 使 用 了 下 和 面 这 种 较 
为 特别 的 属性 加 载 顺序 : 

1. 在 命令 行 中 传 入 的 参数 。 

2.SPRING_APPLICATION_JSON 中 的 属性 。 
SPRING_APPLICATION_JSON 是 以 JSON 格 式 配 置 在 系统 环境 变量 中 的 
内 容 。 

3.java:comp/env 中 的 JNDI 属 性 。 

4.Java 的 系统 属性 ， 可 以 通过 System.getProperties 〈) 获得 的 内 容 。 

5. 操 作 系统 的 环境 变量 。 

6. 通 过 random.* 配 置 的 随机 属性 。 

7. 位 于 当前 应 用 ”jar 包 之 外 ， 针 对 不 同 {profile} 环 境 的 配置 文件 内 
容 ， 例 如 application-{profile}.properties 或 是 YAML 定 义 的 配置 文件 。 

8. 位 于 当前 应 用 ”jar 包 之 内 ， 针 对 不 同 {profile} 环 境 的 配置 文件 内 
容 ， 例 如 application-{profile}.properties 或 是 YAML 定 义 的 配置 文件 。 

9. 位 于 当前 应 用 jar 包 之 外 的 application.properties 和 YAML 配 置 内 容 。 

10. 位 于 当前 应 用 jar 包 之 内 的 application.properties 和 YAML 配 置 内 





11. 在 @Configuration 注 解 修 改 的 类 中 ， 过 @PropertySource 注 解 定 
义 的 属性 。 
12. 应 用 默认 属 性 ， 使 用 SpringApplication.setDefaultProperties 定义 的 
全 


优先 级 按 上 面 的 顺序 由 高 到 低 ， 数 人 字 越 小 优先 级 越 高 。 

可 以 看 到 ， 其 中 第 7 项 和 第 9 项 都 是 从 应 用 jar 包 之 外 读 取 配置 文件 ， 
所 以 ， 实 现 外 部 化 配置 的 原理 束 是 从 此 切入 ， 为 其 指定 外 部 配置 文件 的 
加 载 位 置 来 取代 jar 包 之 内 的 配置 向 容 。 通 过 这 样 的 实现 ， 我 们 的 工程 在 
配置 中 就 变 得 非常 干净 ， 只 需 在 本 地 放置 开发 需要 的 配置 即 可 ， 而 不 用 
关心 其 他 环境 的 配置 ， 由 其 对 应 环境 的 负责 人 去 维护 即 可 。 








临 控 与 管 于 


在 微服 务 架构 中 ， 我 们 将 原本 庞大 的 单 体 系统 拆 分 成 多 个 提供 不 同 
服务 的 应 用 。 昌 然 各 个 应 用 的 内 部 逻辑 因 分 解 而 得 以 简化 ， 但 是 由 于 部 
署 应 用 的 数量 成 倍增 长 ， 使 得 系统 的 维护 复杂 上 度 大 大 提升 。 对 于 运 维 人 
员 来 说 ， 随 着 应 用 的 不 断 增 多 ， 系 统 集 群 中 出 现 故 障 的 频率 也 变 得 越 来 
越 高 ， 虽 然 在 高 可 用 机 制 的 保护 下 ， 个 别 故障 不 会 影响 系统 的 对 外 服 
务 ， 但 是 这 些 频 繁 出 现 的 故障 需要 被 及 时 发 现 和 处 理 才 能 长 期 保证 系统 
处 于 健康 可 用 状态 。 为 了 能 对 这 些 成 倍增 长 的 应 用 做 到 高 效 运 维 ， 传 统 
的 运 维 方式 显然 是 不 合适 的 ， 所 以 我 们 需要 实现 一 套 自 动 化 的 监控 运 维 
机 制 ， 而 这 套 机 制 的 运行 基础 就 是 不 间断 地 收集 各 个 微服 务 应 用 的 各 项 
中标 情况 ， 并 根据 这 些 基础 指标 信息 来 制定 监控 和 预警 规则 ， 更 进一步 
甚至 做 到 一 些 自 动 化 的 运 维 操作 等 。 

为 了 让 运 维系 统 能 够 获取 各 个 微服 务 应 用 的 相关 指标 以 及 实现 一 些 
第 规 操作 控制 ， 我 们 需要 开发 一 套 专 门 用 于 植 入 各 个 微服 务 应 用 的 接口 
供 监 控 系统 采集 信息 。 而 这 些 接口 往往 有 很 大 一 部 分 指标 都 是 类 似 的 ， 
比如 环境 变量 、 垃 圾 收集 信息 、 内 存 信息 、 线 程 池 信 息 等 。 既 然 这 些 信 
奶 那 么 通用 ， 难 道 就 没有 一 个 标准 化 的 实现 框架 吗 ? 

当 我 们 决定 用 Spring ”Boot 来 作为 微服 务 框架 时 ， 除 了 它 强 大 的 快速 
开发 功能 之 外 ， 还 因为 它 在 Starter ”POMs 中 提供 了 一 个 特殊 依赖 模块 
spring-boot-starter-actuator。 引 入 该 模块 能 够 自动 为 Spring Boot 构建 的 应 
用 提供 一 系列 用 于 监控 的 端点 。 同 时 ，Spring Cloud 在 实现 各 个 微服 务 
组 件 的 时 候 ， 进 一 步 为 该 模块 做 了 不 少 扩 展 ， 比 如 ， 为 原生 端点 增加 了 
更 多 的 指标 和 度量 信息 《比如 在 整合 Eureka 的 时 候 会 为 /health 端点 增 
加 相关 的 信息 ) ， 并 且 根 据 不 同 的 组 件 还 提供 了 更 多 有 空 的 端点 《〈 比 
如 ， 为 API 网 关 组 件 Zuul 提 供 了 Amoutes 端 点 来 返回 路 由 信息 ) 。 

spring-boot-starter-actuator 模 块 的 实现 对 于 实施 微服 务 的 中 小 团队 来 
说 ， 可 以 有 效 地 省 去 或 大 大 减少 监控 系统 在 采集 应 用 指标 时 的 开发 量 。 
当然 ， 它 也 并 不 是 万 能 的 ， 有 时 候 也 需要 对 其 做 一 些 简 单 的 扩展 来 帮助 
我 们 实现 自身 系统 个 性 化 的 监控 需求 。 所 以 ， 在 本 节 将 详细 介绍 一 些 关 
于 spring-boot-starter-actuator 模 块 的 内 容 ， 包 括 原生 提供 的 端点 以 及 一 些 
常用 的 扩展 和 配置 方式 等 。 


初 识 actuator 














下 面 ， 我 们 通过 对 “快速 入 门 ? 小 节 中 实现 的 Spring Boot 应 用 增加 
spring-boot-starter-actuator 模 块 功能 ， 来 对 它 有 一 个 直观 的 认识 。 

在 现 有 的 ”Spring Boot 应 用 中 引入 该 模块 非常 简单 ， 只 需要 在 
pom.xml 的 dependency 节 点 中 ， 新 增 spring-boot-starter-actuator 的 依赖 即 
可 ， 有 具体 如 下 : 

<dependency> 

<groupId>org.Springframework.boot</groupId> 

<artifactId>spring-boot-starter-actuator</artifactId> 

</dependency> 

增加 该 依赖 之 后 ， 重 新 启动 应 用 。 此 时 ， 我 们 可 以 在 控制 台中 看 到 
如 下 图 所 示 的 输出 : 
















上 图 显示 了 一 批 端点 定义 ， 这 些 端 点 并 非 我 们 自己 在 程序 中 创建 
的 ， 而 是 由 spring-boot-starter-actuator 模 块根 据 应 用 依赖 和 配置 自动 创建 
出 来 的 监控 和 管理 端点 。 通 过 这 些 端点 ， 我 们 可 以 实时 获取 应 用 的 各 项 
监控 指标 ， 比 如 访问 /health 端 点 。 我 们 可 以 获得 如 下 信息 : 


{ 

"status": "UP", 
"diskSpace": { 
"status": "UP", 


"total": 491270434816, 
"free": 383870214144, 
"threshold": 10485760 
} 


} 

在 没有 引入 其 他 依赖 之 前 ， 该 端点 的 内 容 较 为 简单 ， 后 续 我 们 在 使 
用 Spring Cloud 的 各 个 组 件 之 后 ， 它 的 返回 会 变 得 非常 丰富 ， 这 些 内 容 
将 帮助 我 们 制定 更 为 个 性 化 的 监控 策略 。 


原生 端点 











通过 在 快速 入 门 示例 中 添加 spring-boot-starter-actuator 模 块 ， 我 们 已 
经 对 它 有 了 一 个 初步 的 认识 。 接 下 来 ， 我 们 详细 介绍 一 下 spring-boot- 
starter-actuator 模 块 中 已 经 实现 的 一 些 原 生 端 点。 根据 端点 的 作用 ， 可 以 
将 原生 端点 分 为 以 下 三 大 类 。 

e 应 用 配置 类 : ”获取 应 用 程序 中 加 载 的 应 用 配置 、 环 境 变 量 、 自 动 
化 配置 报告 等 与 Spring Boot 应 用 密切 相关 的 配置 类 信息 。 

e 上 度量 指标 类 : ”获取 应 用 程序 运行 过 程 中 用 于 监控 的 度量 指标 ， 比 
如 内 存 信 息 、 线 程 池 信息 、HTTP 请 求 统计 等 。 

e 探 作 控 制 类 : 提供 了 对 应 用 的 关闭 等 操作 类 功能 。 

下 面 我 们 来 详细 了 解 一 下 这 三 类 端点 都 分 别 可 以 为 我 们 提供 怎样 的 
有 用 信息 和 强大 功能 ， 以 及 我 们 如 何 去 扩 展 和 配置 它们 。 

应 用 配置 类 

由 于 Spring Boot 为 了 改善 传统 Spring 应 用 繁杂 的 配置 内 容 ， 采 用 了 包 
扫描 和 上 自动 化 配置 的 机 制 来 加 载 原 本 集中 于 XML 文件 中 的 各 项 内 容 。 
虽然 这 样 的 做 法 让 我 们 的 代码 变 得 非常 简洁 ， 但 是 整个 应 用 的 实例 创建 
和 依赖 关系 等 信息 都 被 离散 到 了 各 个 配置 类 的 注解 上 ， 这 使 我 们 分 析 整 
个 应 用 中 资源 和 实例 的 各 种 关系 变 得 非常 困难 。 而 这 类 端点 可 以 帮助 我 
们 轻松 获取 一 系列 关于 Spring 应 用 配置 内 容 的 详细 报告 ， 比 如 自动 化 配 
置 的 报告 、Bean 创建 的 报告 、 环 境 属 性 的 报告 等 。 

e/autoconfig: 访问 点 用 来 获取 应 用 的 目 动 化 配置 报告 ， 其 中 包括 所 
有 自动 化 配置 的 候选 项 。 同 时 还 列 出 了 每 个 候选 项 是 否 满足 自动 化 配置 
的 各 个 先决 条 件 。 所 以 ， 访 端点 可 以 帮助 我 们 方便 地 找到 一 些 自动 化 配 
置 为 什么 没有 生效 的 具体 原因 。 该 报告 内 容 将 自动 化 配置 内 容 分 为 以 下 
两 部 分 。 

加 positiveMatches 中 返回 的 是 条 件 匹 配 成 功 的 自动 化 配置 。 

mnegativeMatches 中 返回 的 是 条 件 匹 配 不 成 功 的 自动 化 配置 。 


























"positiveMatches": { // 条 件 匹 配 成 功 的 
"EndpointWebMvcAutoConfiguration": [ 
{ 
CoOndLEIORETOIOnCILRSSCondTEYEOT2 
"message": "conditionalonclass classes found: 
javax.servlet.Servlet,org.springframework.web.servlet.DispatcherServlet" 
}, 
{ 


"condition": "OnWebApplicationCondition", 
"message": "found web application StandardServletEnvironment" 
} 
] ， 
} ， 
"negativeMatches": { // 条 件 匹配 不 成 功 的 


"HealthIndicatorAutoConfiguration.DataSourcesHealthIndicatorConfiguration": [ 
{ 
"condition": "OnClassCondition", 
"message": "required QConditionalOonClass classes not found: 
org.springframework.jdbc.core.JdbcTemplate" 
} 
] 天 


} 


} 

从 如 上 示例 中 我 们 可 以 看 到 ， 每 个 上 自动 化 配置 候选 项 中 都 有 一 系列 
的 条 件 ， 比 如 上 面 没有 成 功 匹配 的 
HealthIndicatorAutoConfiguration.DataSourcesHealthIndicatorConfiguration 
配置 ， 它 的 先决 条 件 是 需要 在 工程 中 包含 
org.springframework.jdbc.core.JdbcTemplate 类 ， 由 于 我 们 没有 引入 相关 
的 依赖 ， 它 就 不 会 执行 自动 化 配置 内 容 。 所 以 ， 当 我 们 发 现 有 一 些 期 望 
的 配置 没有 生效 时 ， 就 可 以 通过 该 端点 来 查看 没有 生效 的 具体 原因 。 

e/beans: 该 端点 用 来 获取 应 用 上 下 文中 创建 的 所 有 Bean。 

[ 


{ 
"context": "hello:dev:8881", 


"parent": null, 

"beans":[ 

{ 

"bean": "org.Springframework.boot.autoconfigure.web. 
DispatcherServletAutoConfiguration$DispatcherServletConfiguration", 
"scope": "singleton", 








Li | 


"type": "org.Springframework.boot.autoconfigure.web. 

DispatcherServletAutoConfiguration$DispatcherServletConfiguration$$E 
CGLIB$$3440282b", 

"resource": "null", 

"dependencies":[ 

"serverProperties", 

"spring.mvc.CONFIGURATION_ PROPERTIES", 

"multipartConfigElement" 

上 

{ 

] 


"bean": "dispatcherServlet", 

"scope": "singleton", 

"type": "org.springframework.web.servlet.DispatcherServlet", 

"resource": "class path resource 

[org/springframework/boot/autoconfigure/web/DispatcherServletAutoCon 
atcherServletConfiguration.class]", 

"dependencies":[] 

} 

] 


} 
] 
在 如 上 示例 中 ， 我 们 可 以 看 到 在 每 个 Bean 中 都 包含 了 下 面 这 些 信 


二 


晶 bean:Bean 的 名 称 。 

四 scope:Bean 的 作用 域 。 

type:Bean 和 的 Java 类 型 。 

resource:class 文 件 的 具体 路 径 。 

dependencies: 依赖 的 Bean 名 称 。 

e/configprops: 访问 点 用 来 获取 应 用 中 配置 的 属性 信息 报告 。 从 下 面 
该 端点 返回 示例 的 片段 中 ， 我 们 看 到 返回 了 关于 该 短信 的 配置 信息 ， 
prefix 属性 代表 了 属性 的 配置 前 级 ，properties 代 表 了 各 个 属性 的 名 称 和 
值 。 所 以 ， 我 们 可 以 通过 该 报告 来 看 到 各 个 属性 的 配置 路 径 ， 比 如 我 们 
要 关闭 该 端点 ， 束 可 以 通过 使 用 endpoints.configprops.enabled=false 来 完 
成 设置 。 

{ 


"configurationPropertiesReportEndpoint": { 
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"prefix": "endpoints.configprops", 
"properties": { 

"id": "configprops", 

"sensitive": true, 

"enabled": true 

} 

上 

} 

e/env: 该 端点 与 /configprops 不 同 ， 它 用 来 毋 取 应 用 所 有 可 用 的 环境 
属性 报告 。 包括 环境 变量 、 JVM 属 性 、 应 用 的 配置 属性 、 命 令 行 中 的 参 
数 。 从 下 面 该 端点 返回 的 示例 片段 中 ， 可 以 看 到 它 不 仅 返 回 了 应 用 的 配 
置 属性 ， 还 返回 了 系统 属性 、 环 境 变 量 等 丰富 的 配置 信息 ， 其 中 还 包括 
了 应 用 还 没有 使 用 的 配置 ， 所 以 它 可 以 帮助 我 们 方便 地 看 到 当前 应 用 可 
以 加 载 的 配置 信息 ， 并 配合 @ConfigurationProperties 注 解 将 它们 引入 到 
我 们 的 应 用 程序 中 来 进行 使 用 。 另 外 ， 为 了 配置 属性 的 安全 ， 对 于 一 些 
类 似 密码 等 敏感 信息 ， 该 端点 都 会 进行 隐私 保护 ， 但 是 我 们 需要 让 属性 
名 中 包含 password、secret、key 这 些 关 键 词 ， 这 样 该 端点 在 返回 它们 的 
时 候 会 使 用 * 来 苦 代 实际 的 属性 值 。 

{ 

"profiles":[ 

"dev" 

]， 

"server.ports": { 

"local.server.port": 8881 

所 

"servletContextInitParams": { 

中 

"systemProperties": { 

"idea.version": "2016.1.3", 

"java.runtime.name": "Java (TM) SE Runtime Environment", 

"sun.boot.library.path": "C:\Program Files\avaNdk1.8.0 91NreNbin” 

"java.vm.version": "25.91-b15", 

"java.vm.vendor": "Oracle Corporation", 
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}, 


"systemEnvironment": { 


"configsetroot": "C:NWINDOWSNConfigSetRoot ， 
"RABBITMQ_BASE": "E:\\tools\rabbitmq", 

}, 
"applicationConfig:[classpath:/application-dev.properties]": { 
"server.port": "8881" 

}, 
"applicationConfig:[classpath:/application.properties]": { 
"server.port": "8885", 

"spring.profiles.active": "dev", 

"info.app.name": "spring-boot-hello", 
"info.app.version": "v1.0.0", 

"spring.application.name": "hello" 


} 

e/mappings: 该 端点 用 来 返回 所 有 Spring MVC 的 控制 器 映射 天 系 报 
告 。 从 下 面 的 示例 片段 中 ， 我 们 可 以 看 到 访 报 告 的 信息 与 我 们 在 局 用 
Spring MVC 的 Web 应 用 时 输出 的 日 志 信 息 类 似 ， 其 中 bean 属 性 标识 了 该 
映射 关系 的 请 求 处 理 器 ，method 属 性 标识 了 该 映射 关系 的 具体 处 理 类 和 
处 理 函 数 。 

{ 

"/webjars/**": { 


LL | 


"bean": "resourceHandlerMapping" 
和 
"/ 米 米 "。 { 


LL | 


"bean": "resourceHandlerMapping" 
人 

"/**/favicon.ico": { 

"bean": "faviconHandlerMapping" 
le 
"{[/hello]}": { 

"bean": "requestMappingHandlerMapping", 





"method": "public java.lang.String 
com.didispace.web.HelloController.index () " 

}, 

"{[/mappings | /mappings.json],methods=[GET],produces= 


[application/json]}": { 


1 。IT 


"bean": "endpointHandlerMapping", 
"method": "public java.lang.Object 
org.springframework.boot.actuate.endpoint.mvc.Endpoint MvcA dapter.inv 


} 

e/info: 该 端点 用 来 返回 一 些 应 用 自 定义 的 信息 。 默 认 情 况 下 ， 该 新 
点 只 会 返回 一 个 空 的 JSON 内 容 。 我 们 可 以 在 application.properties 配 置 文 
件 中 通过 info 前 级 来 设置 一 些 属性 ， 比 如 下 面 这 样 : 

info.app.name=spring-boot-hello 

info.app.version=v1.0.0 

再 访问 /info 病 点 ， 我 们 可 以 得 到 下 面 的 返回 报告 ， 其 中 就 包含 了 上 
面 我 们 在 应 用 中 自 定义 的 两 个 参数 。 

{ 











"app": { 
"name": "spring-boot-hello", 
"version": "v1.0.0" 


} 


} 

度量 指标 类 

上 面 我 们 所 介绍 的 应 用 配置 类 端点 所 提供 的 信息 报告 在 应 用 局 动 的 
时 候 束 已 经 基本 确定 了 其 返回 内 容 ， 可 以 说 是 一 个 静态 报告 。 而 度量 指 
标 类 问 点 提供 的 报告 内 容 则 是 动态 变化 的 ， 这 些 冰 点 提供 了 应 用 程序 在 
运行 过 程 中 的 一 些 快照 信息 ， 比 如 内 存 使 用 情况 、HTTP 请 求 统 计 、 外 
部 资源 指标 等 。 这 些 端点 对 于 我 们 构建 微服 务 架 构 中 的 监控 系统 非常 有 
帮助 ， 由 于 Spring Boot 必 用 自身 实现 了 这 些 端点 ， 所 以 我 们 可 以 很 方便 
地 利用 它们 来 收集 我 们 想 要 的 信息 ， 以 制定 出 各 种 自动 化 策略 。 下 面 ， 
我 们 就 来 分 别 看 看 这 些 强大 的 端点 功能 。 

e/metrics: 该 端点 用 来 返回 当前 应 用 的 各 类 重要 度量 指标 ， 比 如 内 
存 信 息 、 线 程 信 息 、 垃 圾 回收 信息 等 。 














{ 

"mem": 541305, 

"mem.free": 317864, 
"processors": 8, 
"instance.uptime": 33376471, 
"uptime": 33385352, 
"systemload.average":-1, 


"heap.committed": 476672， 
"heap.init": 262144, 
"heap.used": 158807, 

"heap": 3701248, 
"nonheap.committed": 65856, 
"nonheap.init": 2496, 
"nonheap.used": 64633, 
"nonheap": 0, 

"threads.peak": 22， 
"threads.daemon": 20， 
"threads.totalStarted": 26, 
"threads": 22， 

"classes": 7669， 
"classes.loaded": 7669, 
"classes.unloaded": 0, 
"gc.ps_scavenge.count": 7, 
"gc.ps_scavenge.time": 118, 
"gc.ps_marksweep.count": 2, 
"gc.ps_marksweep.time": 234, 
"httpsessions.max":-1, 
"httpsessions.active": 0, 
"gauge.response.beans": 55, 
"gauge.response.env": 10, 
"gauge.response.hello": 5, 
"gauge.response.metrics": 4, 
"gauge.response.configprops": 153, 
"gauge.response.star-star": 5, 
"counter.status.200.beans": 1, 
"counter.status.200.metrics": 3, 
"counter.status.200.configprops": 1, 
"counter.status.404.star-star": 2, 
"counter.status.200.hello": 11, 
"counter.status.200.env": 1 


} 

从 上 面 的 示例 中 ， 我 们 看 到 有 如 下 这 些 重 要 的 度量 值 。 

四 系统 信息 : 包括 处 理 器 数量 processors、 运 行 时 间 uptime 和 
instance.uptime、 系 统 平均 负载 systemload.average。 





mem.*: 内 存 概要 信息 ， 包 括 分 配给 应 用 的 总 内 存 数量 以 及 当前 空 
闪 的 内 存 数量 。 这 些 信息 来 自 java.lang.Runtime。 

@@heap.*: 堆 内 存 使 用 情况 。 这 些 信 息 来 自 
java.lang.management.MemoryMXBean 接口 中 getHeapMemoryUsage 方 
法 获取 的 java.lang.management.MemoryUsage。 

mnonheap.*: 非 堆 内 存 使 用 情况 。 这 些 信 息 来 自 
java.lang.management.MemoryMXBean 接 口中 getNonHeapMemoryUsage 
方法 获取 的 java.lang.management.MemoryUsage。 

国 threads.*: 线程 使 用 情况 ， 包 括 线 程 数 、 守 护 线程 数 (daemon) 、 
线程 峰值 (peak) 和 等， 这些 数据 均 来 自 
java.lang.management.IhreadMXBean。 

加 classes.*: 应 用 加 载 和 芭 载 的 类 统计 。 这 些 数 据 均 来 自 
java.lang.management.ClassLoadingMXBean。 

加 gc.*: 垃圾 收集 器 的 详细 人 信息， 包括 垃圾 回收 次 数 
gc.ps_scavenge.count、 垃 圾 回收 消耗 时 间 gc.ps_scavenge.time、 标 记 - 清 
除 算法 的 次 数 gc.ps_marksweep.count、 标 记 - 清 除 算法 的 消耗 时 间 
gc.ps_marksweep.time。 这 些 数 据 均 来 自 
java.lang.management.GarbageCollector MX Bean.。 

mhttpsessions.*:Tomcat 容器 的 会 话 使 用 情况 。 包 括 最 大 会 话 数 
httpsessions.max 和 活跃 会 话 数 httpsessions.active。 该 度量 指标 信息 仅 在 
引入 磐 入 式 Tomcat 作 为 应 用 容器 的 时 候 才 会 提供 。 

国 gauge.*:HTTP 请 求 的 性 能 指标 之 一 ， 它 主要 用 来 反映 一 个 绝对 数 
值 。 比 如 上 面 示例 中 的 gauge.response.hello: 5， 它 表示 上 一 次 hello 请 求 
的 延迟 时 间 为 5 量 秒 。 

counter.*:HTTP 请 求 的 性 能 指标 之 一 ， 它 主要 作为 计数 器 来 使 用 ， 
记录 了 增加 量 和 减少 量 。 上 述 示例 中 的 counter.status.200.hello: 11， 它 代 
表 了 hello 请 求 返 回 200 状 态 的 次 数 为 11。 

对 于 gauge.* 和 counter.* 的 统计 ， 这 里 有 一 个 特殊 的 内 容 请 求 star- 
star， 它 代表 了 对 静态 资源 的 访问 。 这 两 类 上 度量 指标 非常 有 用 ， 我 们 不 
仪 可 以 使 用 它 默 认 的 统计 指标 ， 还 可 以 在 程序 中 轻松 地 增加 自 定义 统计 
值 。 只 需要 通过 注入 
org.springframework.boot.actuate.metrics.CounterService 和 
org.springframework.boot.actuate.metrics.GaugeService 来 实现 自 定义 的 统 
计 指 标 信息 。 比 如 我 们 可 以 像 下 面 这 样 自 定 义 实 现 对 hello 接 口 的 访问 次 
数 统 计 。 

(DRestController 

public class HelloController { 


























(OAutowired 

private CounterService counterService; 

@RequestMapping ("/hello") 

public String greet () { 

counterService.increment ("didispace.hello.count") ; 

return ”; 

} 

} 

/metrics 端 点 可 以 提供 应 用 运行 状态 的 完整 度量 指标 报告 ， 这 项 功能 
非常 实用 ， 但 是 对 于 监控 系统 中 的 各 项 监控 功能 ， 它 们 的 监控 内 容 、 数 
据 收 集 频率 都 有 所 不 同 ， 如 果 每 次 都 通过 全 量 获 取 报 告 的 方式 来 收集 ， 
略 显 粗 又。 所 以 ， 我 们 还 可 以 通过 /metrics/{fname} 接 口 来 更 细 粒 度 地 获 
取 度 量 信息 ， 比 如 可 以 通过 访问 /metrics/mem.free 来 获取 当前 可 用 内 存 
数量 。 

e/health: 该 端点 在 一 -开始 的 示例 中 我 们 已 经 使 用 过 了 ， 它 用 来 获取 
应 用 的 各 类 健康 指 标 信息 = 在 spring- boot-starter-actuator 模 块 中 自 带 实现 
了 一 些 常 用 资源 的 健康 指标 检测 占 。 这 些 检测 器 都 通过 HealthIndicator 
口 实现 ， 并 且 会 根据 依赖 关系 的 引入 实现 自动 化 装配 ， 比 如 下 面 列 出 

检测 器 功能 
DiskSpaceHealthIndicator | 低 磁 盘 空间 检测 


DataSourceHealthIndicator 检测 DataSource 的 连接 是 否 可 用 














MongoHealthIndicator 检测 Mongo 数据 库 是 否 可 用 
RabbitHealthIndicator | 检测 Rabbit 服务 器 是 否 可 用 
RedisHealthIndicator | 检测 Redis 服务 器 是 否 可 用 
SolrHealthIndicator 检测 Solr 服务 器 是 否 可 用 























有 了 时候， 我 们 可 能 还 会 用 到 一 些 Spring Boot 的 Starter POMs 中 还 没有 
封装 的 产品 来 进行 开发 ， 比 如 ， 当 使 用 RocketMQ 作 为 消 轧 代理 时 ， 由 
于 没有 上 自动 化 配置 的 检测 器 ， 所 以 需要 目 己 来 实现 一 个 用 来 采集 健康 信 
恩 的 检测 器 。 我 们 可 以 在 Spring Boot 的 应 用 中 ， 为 
org.Springframework.boot.actuate.health.HealthIndicator ”接口 实现 一 个 对 
RocketMQ 的 检测 器 类 : 

@Component 

public class Rocket MQHealthIndicator implements HealthIndicator { 

(DOverride 

public Health health () { 

int errorCode=check 〈) ; 





if (errorCode !=0) { 


return Health.down () .withDetail ("Error 
Code",errorCode) .build (); 

} 

return Health.up () .build (); 

} 


private int check () { 

/对 监控 对 象 的 检测 操作 

} 

} 

通过 重 写 health〈) 函数 可 实现 健康 检查 ， 在 返回 的 Heath 对 象 中 ， 
共有 两 项 内 容 ， 一 个 是 状态 信息 ， 除 了 该 示例 中 的 UP 与 DOWN 之 
外 ， 还 有 _ UNKNOWN 和 OUT_OF SERVICE， 可 以 根据 需要 来 实现 返 
回 ; 还 有 一 个 详细 信息 ， 采 用 Map 的 方式 存储 ， 在 这 里 通过 withDetail 
函数 ， 注 入 了 一 个 Eror Code 人 信息， 我 们 也 可 以 填 入 其 他 信息 ， 比 如 ， 
检测 对 象 的 下 地 址 、 端 口 等 。 

重新 启动 应 用 ， 并 访问 /health 接 口 ， 我 们 在 返回 的 JSON 字 符 串 中 ， 
将 会 包含 如 下 信息 : 

"rocket MQ": { 

"status": "UP" 

} 

e/dump: 该 端点 用 来 暴露 程序 运行 中 的 线程 信息 。 它 使 用 
java.lang.management.ThreadMXBean 的 dumpAllThreads 方 法 来 返回 所 有 
含有 同步 信息 的 活动 线程 详情 。 

e/trace: 该 端点 用 来 返回 基本 的 HITP 跟 踪 信 息 。 默 认 情 况 下 ， 跟 踩 
信息 的 存储 采用 
org.Springframework.boot.actuate.trace.InMemoryTraceRepository 实 现 的 内 
存 方式 ， 始 终 保 留 最 近 的 100 条 请 求 记录 。 它 记录 的 内 容 格式 如 下 所 
外: 

















"timestamp": 1482570022463， 
bi oh 和 区 天 
method®s em 
"path": "“/metrics/mem", 
"headers"; { 
"request": 1 
SOC 人 本 在 dea. 
"connection": "keep-alive", 
"cache-control": "no-cache", 
"user-agent": "Mozilla/5.0 (Windows NT 10.0; WOW64) 
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36", 
"postman-token": "9817ea4d-ad9d-b2fc-7685-9dfflalbc193", 
DEC 人生 
"accept-encoding": "gzip, deflate, sdch", 
"accept-language": "zh-CN,zh;q=0.8" 
| 


"response": { 
"Xx-Application-Context": "hello:dev:8881", 
"Content-Type": "application/json;charset=UTF-8", 
"Transfer-Encoding": "chunked", 
Dabens "Sa A Dec Zo OOa00a22 CMD 
"ebatuse T2000” 


} 
}， 


] 

操作 控制 类 

仔细 的 读者 可 能 会 发 现 ， 我 们 在 “ 初 识 actuator” 小 节 中 的 示例 的 控制 
台中 输出 的 所 有 监控 器 点， 已 经 在 介绍 应 用 配置 类 端点 和 度量 指标 类 端 
点 时 都 讲解 完了 。 那 么 还 有 哪些 是 操作 控制 类 端点 昵 ? 实际 上 ， 由 于 之 
前 介绍 的 所 有 端点 都 是 用 来 反映 应 用 自 员 的 属性 或 是 运行 中 的 状态 ， 相 
对 于 操作 控制 类 端点 没有 那么 敏感 ， 所 以 它们 都 是 默认 局 用 的 。 而 操作 
控制 类 端点 拥有 更 强大 的 控制 能 力 ， 如 果 要 使 用 它们 的 话 ， 需 要 通过 属 
性 来 配置 开局 操作 。 

在 原生 端点 中 ， 只 提供 了 一 个 用 来 关闭 应 用 的 端点 : /shutdown 在 
后 续 我 们 引入 了 Eureka 之 后 ， 会 引入 更 多 控制 端点 ) 。 可 以 通过 如 下 配 
罩 天 局 它 ， 

endpoints.shutdown.enabled=true 

在 配置 了 上 述 属性 之 后 ， 只 需要 访问 该 应 用 的 /shutdown 端 点 束 能 实 
现 关 闭 该 应 用 的 远程 操作 。 由 于 开放 关闭 应 用 的 操作 本 喘 是 一 件 非常 危 
险 的 事 ， 所 以 真正 在 线 上 使 用 的 时 候 ， 需 要 对 其 加 入 一 定 的 保护 机 制 ， 

















比如 定制 actuator 的 端点 路 径 、 整 合 Spring Security 进 行 安 全 校 验 等 。 


x 


本 章 我 们 通过 构建 一 个 最 基本 的 Spring ” Boot 工程 ， 让 大 家 对 其 有 了 
一 个 最 直观 的 感受 。 同 时 ， 也 为 后 续 构 建 各 类 Spring ” Cloud 组 件 和 微服 
务 应 用 做 了 一 些 基 础 准备 工作 。 另 外 ， 我 们 对 Spring Boot 中 的 配置 原理 
以 及 监控 管理 做 了 深入 的 介绍 ， 因 为 这 些 内 容 将 在 后 续 的 介绍 中 有 所 涉 
及 ， 并 且 它 们 有 助 于 理解 Spring Cloud 组 件 的 运行 原理 。 更 多 关于 使 用 
Spring Boot 开 发 微服 务 应 用 的 内 容 ， 我 们 不 在 本 书 中 详细 介绍 ， 读 者 可 
参阅 官方 文档 或 其 他 书籍 资料 来 学 习 。 








第 3 草 ”服务 治理 :Spring Cloud 


Eureka 


Spring Cloud Eureka 是 Spring Cloud Netflix 微服 务 套件 中 的 一 部 分 ， 
它 基 于 Netflix Eureka 做 了 二 次 封装 ， 主 要 负责 完成 微服 务 架构 中 的 服 
务 治 理 功能 。Spring Cloud 通过 为 Eureka 增 加 了 Spring Boot 风 格 的 自动 
化 配置 ， 我 们 只 需 通过 简单 引入 依赖 和 注解 配置 就 能 让 Spring Boot 构 建 
的 微服 务 应 用 轻松 地 与 Eureka 服 务 治 理 体系 进行 整合 。 

在 本 章 中 ， 我 们 将 指引 读者 学 习 下 面 这 些 核心 内 容 ， 并 构建 起 用 于 
服务 治理 的 基础 设施 。 

e 构 建 服 务 注册 中 心 

e 服 务 注册 与 服务 发 现 

eEureka 的 基础 架构 

eEureka 的 服务 治理 机 制 

eEureka 的 配置 


服务 治理 可 以 说 是 微服 务 架 构 中 最 为 核心 和 基础 的 模块 ， 它 主要 用 
来 实现 各 个 微服 务实 例 的 自动 化 注册 与 发 现 。 为 什么 我 们 在 微服 务 架 构 
| 
吗 ? 

在 最 初 开始 构建 微服 务 系统 的 时 候 可 能 服务 并 不 多 ， 我 们 可 以 通过 
做 一 些 静态 配置 来 完成 服务 的 调用 。 比 如 ， 有 两 个 服务 A 和 B， 其 中 服 
务 A 需 要 调用 服务 B 来 完成 一 个 业务 操作 时 ， 为 了 实现 服务 B 的 高 可 用 ， 
不 论 采 用 服务 端 负载 均衡 还 是 客户 端 负 载 均衡 ， 都 需要 手工 维护 服务 B 
的 有 具体 实例 清单 。 但 是 随 着 业务 的 发 展 ， 系 统 功能 越 来 越 复 杂 ， 相 应 的 
微服 务 应 用 也 不 断 增 加 ， 我 们 的 静态 配置 就 会 变 得 越 来 越 难以 维护 。 并 
且 面 对 不 断 发 展 的 业务 ， 我 们 的 集群 规模 、 服 务 的 位 置 、 服 务 的 命名 等 
都 有 可 能 发 生变 化 ， 如 果 还 是 通过 手工 维护 的 方式 ， 那 么 极 易 发 生 错 误 
0 

为 了 解决 微服 务 架 构 中 的 服务 实例 维护 问题 ， 产 生 了 大 量 的 服务 治 
理 框 架 和 产品 。 这 些 框 架 和 产品 的 实现 都 围绕 着 服务 注册 与 服务 发 现 机 
制 来 完成 对 微服 务 应 用 实例 的 自动 化 管理 。 

e 服 务 注册 : 在 服务 治理 框架 中 ， 通 常 都 会 构建 一 个 注册 中 心 ， 每 
个 服务 单元 同 注册 中 心 登 记 上 自己 提供 的 服务 ， 将 主机 与 端口 号 、 版 本 
号 、 通 信 协 议 等 一 些 附 加 信息 告知 注册 中 心 ， 注 册 中 心 按 服 务 名 分 类 组 
织 服务 清单 。 比 如 ， 我 们 有 两 个 提供 服务 A 的 进程 分 别 运行 于 
192.168.0.100:8000 和 192.168.0.101:8000 位 置 上 ， 另 外 还 有 三 个 提供 服务 
B 的 进程 分 别 运行 于 192.168.0.100:9000、192.168.0.101:9000、 
192.168.0.102:9000 位 置 上 。 当 这 些 进 程 均 启动 ， 并 向 注册 中 心 注册 自己 
的 服务 之 后 ， 注 册 中 心 就 会 维护 类 似 下 面 的 一 个 服务 清单 。 

另外， 服务 注册 中 心 还 需要 以 心跳 的 方式 去 监测 清单 中 的 服务 是 否 
可 用 ， 知 不 可 用 需要 从 服务 清单 中 剔除 ， 达 到 排除 故障 服务 的 效果 。 














服务 名 


服务 A 192.168.0.100:8000、192.168.0.101:8000 





192.168.0.100:9000、192.168.0.101:9000、192.168.0.102:9000 

e 服 务 发 现 : ”由 于 在 服务 治理 框架 下 运作 ， 服 务 间 的 调用 不 再 通过 
指定 具体 的 实例 地 址 来 实现 ， 而 是 通过 同 服 务 名 发 起 请 求 调用 实现 。 所 
以 ， 服 务 调用 方 在 调用 服务 提供 方 接口 的 时 候 ， 并 不 知道 具体 的 服务 实 


例 位 置 。 因 此 ， 调 用 方 需要 向 服务 注册 中 心 咨询 服务 ， 并 获取 所 有 服务 
的 实例 清单 ， 以 实现 对 具体 服务 实例 的 访问 。 比 如 ， 现 有 服务 C 和 希望 调 
用 服务 A， 服 务 C 就 需要 向 注册 中 心 发 起 咨询 服务 请 求 ， 服 务 注册 中 心 
就 会 将 服务 A 的 位 置 清 单 返回 给 服务 C， 如 按 上 例 服务 A 的 情况 ，C 便 获 
得 了 服务 A 的 两 个 可 用 位 置 192.168.0.100:8000 和 192.168.0.101:8000。 当 
服务 C 要 发 起 调用 的 时 候 ， 便 从 该 清单 中 以 某 种 轮 询 策略 取出 一 个 位 置 
来 进行 服务 调用 ， 这 就 是 后 续 我 们 将 会 介绍 的 客户 端 负载 均衡 。 这 里 我 
们 只 是 列举 了 一 种 简单 的 服务 治理 逻辑 ， 以 方便 理解 服务 治理 框架 的 基 
本 运行 思路 。 实 际 的 框架 为 了 性 能 等 因素 ， 不 会 采用 每 次 都 癌 服 务 注 册 
中 心 获取 服务 的 方式 ， 并 且 不 同 的 应 用 场景 在 缓存 和 服务 剔除 等 机 制 上 
也 会 有 一 些 不 同 的 实现 策略 。 








Netflix Eureka 


Spring Cloud Eureka， 使 用 Netflix Eureka 来 实现 服务 注册 与 发 现 ， 它 
既 包 含 了 服务 端 组 件 ， 也 包含 了 客户 端 组 件 ， 并 且 服 务 问 与 客户 端 均 采 
用 Java 编 写 ， 所 以 Eureka 主 要 适用 于 通过 Java 实 现 的 分 布 式 系统 ， 或 是 
与 JVM 兼 容 语 言 构 建 的 系统 。 但 是 ， 由 于 Eureka 服 务 端 的 服务 治理 机 制 
提供 了 完备 的 RESTful API， 所 以 它 也 支持 将 非 Java 语 言 构建 的 微服 务 应 
用 纳入 Eureka 的 服务 治理 体系 中 来 。 只 是 在 使 用 其 他 语言 平台 的 时 候 ， 
需要 上 自己 来 实现 Eureka 的 客户 端 程序 。 不 过 庆幸 的 是 ， 在 目前 几 个 较为 
流行 的 开发 平台 上 ， 都 已 经 有 了 一 些 针 对 Eureka 注册 中 心 的 客户 端 实 
现 框架 ， 比 如 .NET 平台 的 Steeltoe、Node.js 的 eureka-js-client 等 。 

Eureka 服 务 端 ， 我 们 也 称 为 服务 注册 中 心 。 它 同 其 他 服务 注册 中 心 
一 样 ， 文 持 高 可 用 配置 。 它 依托 于 强 一 致 性 提供 良好 的 服务 实例 可 用 
性 ， 可 以 应 对 多 种 不 同 的 故障 场景 。 如 果 Eureka 以 集群 模式 部 署 ， 当 
集群 中 有 分 片 出 现 故 障 时 ， 那 么 Eureka 就 转 入 自我 保护 模式 。 它 允许 
在 分 片 故 障 期 间 继续 提供 服务 的 发 现 和 注册 ， 当 故障 分 片 恢复 运行 时 ， 
集群 中 的 其 他 分 片 会 把 它们 的 状态 再 次 同步 回来 。 以 在 AWS 上 的 实践 
为 例 ，Netflix 推荐 每 个 可 用 的 区 域 运 行 一 个 Eureka 服 务 问 ， 通 过 它 来 形 
成 集群 。 不 同 可 用 区 域 的 服务 注册 中 心 通 过 异步 模式 互相 复制 各 自 的 状 
i i i 
微 甜 别 的 。 

Eureka 客 户 端 ， 主 要 处 理 服务 的 注册 与 发 现 。 客 户 端 服务 通过 注解 
和 参数 配置 的 方式 ， 髓 入 在 客户 端 应 用 程序 的 代码 中 ， 在 应 用 程序 运行 
时 ，Eureka 客 户 病 癌 注 册 中 心 注册 自身 提供 的 服务 并 周期 性 地 发 送 心 跳 
来 更 新 它 的 服务 租约 。 同 时 ， 它 也 能 从 服务 端 查 询 当 前 注册 的 服务 信息 














并 把 它们 缓存 至 ela 期 性 地 刷新 服务 状态 。 
下 面 我 们 来 构建 一 些 简 单 示 例 ， 学 习 如 何 使 用 Eureka 构 建 注册 中 心 
以 及 进行 注册 与 发 现 服务 ， 


营建 服务 注册 中 心 


首先 ， 创 建 一 个 基础 的 Spring Boot 工 程 ， 命 名 为 eureka-server， 并 在 
pom.xml 中 引入 必要 的 依赖 内 容 ， 代 但 如 下 : 

<parent> 

<groupId>org.Springframework.boot</groupId> 

<artifactId>spring-boot-starter-parent</artifactId> 

<version>1.3.7.RELEASE</version> 

<relativePath/> 

</parent> 

<dependencies> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-eureka-server</artifactId> 

</dependency> 

</dependencies> 

<dependencyManagement> 

<dependencies> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-dependencies</artifactId> 

<version>Brixton.SR5</version> 

<type>pom</type> 

<scope>import</scope> 

</dependency> 

</dependencies> 

</dependencyManagement> 

通过 @EnablepurekaServer 注 解 启 动 一 个 服务 注 册 中 心 提供 给 其 他 应 
用 进行 对 话 。 这 一 步 非常 简单 ， 只 需 在 一 个 普通 的 Spring Boot 应 用 中 添 
加 这 个 注解 就 能 开局 此 功能 ， 比 如 下 面 的 例 了 

(EnableEurekaServer 

SpringBootApplication 

public class Application { 





public static void main (String[Jargs) { 
new 
SpringApplicationBuilder (Application.class) .web (true) .run Cargs) ; 


} 

在 默认 设置 下 ， 该 服务 注册 中 心 也 会 将 自己 作为 客户 端 来 尝试 注册 
它 自己 ， 所 以 我 们 需要 禁用 它 的 客户 端 注 册 行 为 ， 只 需 在 
application.properties 中 增加 如 下 配置 : 

server.port=1111 

eureka.instance.hostname=localhost 

eureka.client.register-with-eureka=false 

eureka.client.fetch-registry=false 

eureka.client.serviceUTrl.defaultZone=http://${eureka.instance.hostname}:: 
mo eure ee 

由 于 后 续 内 0 为 了 与 后 续 要 进行 注册 的 服务 区 
分 ， 这 里 将 服务 注册 中 心 的 端口 通过 server.port 属 性 设置 为 1111。 

eeureka.client.register-with-eureka: 由 于 该 应 用 为 注册 中 心 ， 所 以 设 
置 为 false， 代 表 不 同 注册 中 心 注册 自己 。 

eeureka.client.fetch-registry: 由 于 注册 中 心 的 职 贡 惑 是 维护 服务 实 
例 ， 它 并 不 需要 去 检索 服务 ， 所 以 也 设置 为 false。 

人 
看 到 如 下 图 所 下 1 的 Eureka 信 息 面 板 ， 其 中 Instances currently registered 
with Eureka 栏 是 室 的 ， 说 明 该 注册 中 心 还 :没有 注册 任何 服务 。 








System Status 


DS Replicas 








注册 服务 提供 者 


在 完成 了 服务 注册 中 心 的 搭建 之 后 ， 接 下 来 我 们 尝试 将 一 个 既 有 的 
Spring Boot 应 用 加 入 Eureka 的 服务 治理 体系 中 去 。 

可 以 使 用 上 一 章 中 实现 的 快速 入 门 工程 来 进行 改造 ， 将 其 作为 一 个 
微服 务 应 用 向 服务 注册 中 心 发 布 自己 。 首 先 ， 修 改 pom.xml， 增 加 
Spring Cloud Eureka 模 块 的 依赖 ， 具 体 代码 如 下 所 示 : 

<dependencies> 

<dependency> 

<groupId>org.Springframework.boot</groupId> 

<artifactId>spring-boot-starter-web</artifactId> 

</dependency> 

<dependency> 

<groupId>org.Springframework.boot</groupId> 

<artifactId>spring-boot-starter-test</artifactId> 

<scope>test</scope> 

</dependency> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-eureka</artifactId> 

</dependency> 

</dependencies> 

<dependencyManagement> 

<dependencies> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-dependencies</artifactId> 

<version>Brixton.SR5</version> 

<type>pom</type> 

<scope>import</scope> 

</dependency> 

</dependencies> 

</dependencyManagement> 

接着 ， 改 造 /hello 请 求 处 理 接口 ， 通 过 注入 DiscoveryClient 对 象 ， 在 
日 志 中 打印 出 服务 的 相关 内 容 。 

(DRestController 

public class HelloController { 








private final Logger logger=Logger.getLogger (getClass () ) ; 
(OAutowired 
private DiscoveryClient client; 
@RequestMapping (value="/hello",method=RequestMethod.GET) 
public String index () { 
ServiceInstance instance=client.getLocalServiceInstance (); 
logger.info ("/hello,host:"+instance.getHost 〈 ) 

+",service id:"+instance.getServiceld () ) ; 
return "Hello World"; 
} 


} 

然后 ， 在 主 类 中 通过 加 上 @EnableDiscoveryClient 注解 ， 激 活 Eureka 
中 的 DiscoveryClient 实 现 〈 自 动 化 配置 ， 创 建 DiscoveryClient 接 口 针对 
Eureka 客 户 端的 EurekaDiscoveryCjlient 实 例 ) ， 才 能 实现 上 述 Controller 
中 对 服务 信息 的 输出 。 

@EnableDiscoveryCljlient 

SpringBootApplication 

public class HelloApplication { 

public static void main (String[largs) { 

SpringApplication.run (HelloApplication.class,args) ; 

} 


} 

最 后 ， 我 们 需要 在 application.properties 配置 文件 中 ， 通 过 
spring.application.name 属性 来 为 服务 命名 ， 比 如 命名 为 hello-service。 再 
通过 eureka.client.serviceUrl.defaultZone ”属性 来 指定 服务 注册 中 心 的 地 
址 ， 这 里 我 们 指定 为 之 前 构建 的 服务 注册 中 心地 址 ， 完 整 配置 如 下 所 
人 外: 

spring.application.name=hello-service 

eureka.client.serviceUTrl.defaultZone=http://localhost:1111/eureka/ 

下 面 我 们 分 别 启 动 服务 注册 中 心 以 及 这 里 改造 后 的 hello-service 服 
务 。 在 hello-service 服 务 控制 台中 ，Tomcat 局 动 之 后 ， 
com.netflix.discovery.DiscoveryClient 对 象 打 印 了 该 服务 的 注册 信息 ， 表 
示 服 务 注册 成 功 。 

s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on 
port (s) :8080 (http) 

c.n.e.EurekaDiscoveryClientConfiguration : Updating port to 8080 

com.didispace.HelloApplication : Started HelloApplication 


in 7.218 

seconds (JVM running for 11.646 ) 

com.netflix.discovery.DiscoveryClient : DiscoveryClient HELLO- 
SERVICE/PC- 

201602152056:hello-service-registration status: 204 

而 此 时 在 服务 注册 中 心 的 控制 台中 ， 可 以 看 到 类 似 下 面 的 输出 ， 名 
为 hello-service 的 服务 被 注册 成 功 了 。 

c.n.e.registry.AbstractInstanceRegistry : Registered instance 

HELLO-SERVICE/PC-201602152056:hello-service with status 
UP (replication=true) 

我 们 也 可 以 通过 访问 Eureka 的 信息 面板 ， 在 Instances currently 
registered with Eureka 一 栏 中 看 到 服务 的 注册 信息 。 


Instances currently registered with Eureka 
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HELLO-SERVICE 


通过 访问 http://localhost:8080/hello， 直 接 向 该 服务 发 起 请 求 ， 在 控制 
台中 可 以 看 到 如 下 输出 : 

com.didispace.web.HelloController : /hello,host:PC- 
201602152056， 

service_id:hello-service 

这 些 输出 内 容 就 是 之 前 我 们 在 HelloController 中 注入 的 
DiscoveryClient 接 口 对 象 ， 从 服务 注册 中 心 获 取 的 服务 相关 信息 。 











在 微服 务 架构 这 样 的 分 布 式 环境 中 ， 我 们 需要 充分 考虑 发 生 故 障 的 
情况 ， 所 以 在 生产 环境 中 必须 对 各 个 组 件 进行 高 可 用 部 晋 ， 对 于 微服 务 
如 此 ， 对 于 服务 注册 中 心 也 一 样 。 但 是 到 本 节 为 止 ， 我 们 一 直 都 在 使 用 
单 节点 的 服务 注册 中 心 ， 这 在 生产 环境 中 显然 并 不 合适 ， 我 们 需要 构建 
高 可 用 的 服务 注册 中 心 以 增强 系统 的 可 用 性 。 

Eureka Server 的 设计 一 开始 就 考虑 了 高 可 用 问题 ， 在 Eureka 的 服务 治 
理 设计 中 ， 所 有 太太 即 古 服务 提供 方 ， 也 是 服务 少 费 方 ， 服 务 注册 宁 心 
也 不 例外 。 是 否 还 记得 在 单 市 点 的 配置 中 ， 我 们 设置 过 下 面 这 两 个 参 
数 ， 让 服务 注册 中 心 不 注 册 自 己 : 

eureka.client.register-with-eureka=false 

eureka.client.fetch-registry=false 


Eureka Server 的 高 可 用 实际 上 就 是 将 自己 作为 服务 癌 其 他 服务 注册 中 








心 注册 自己 ， 这 样 就 可 以 形成 一 组 互相 注册 的 服务 注册 中 心 ， 以 实现 服 
务 清 蛙 的 互相 同步 ， 达 到 高 可 用 的 效果 。 下 面 我 们 就 来 尝试 搭建 蜗 可 用 
服务 注册 中 心 的 集群 。 可 以 在 本 章 第 1 节 中 实现 的 服务 注册 中 心 的 基础 
之 上 进行 扩展 ， 构 建 一 个 双 市 点 的 服务 注册 中 心 集群 。 

e 创 建 application-peerl.properties， 作 为 peer1 服 务 中 心 的 配置 ， 并 将 
serviceUrl 指 向 peer2: 

spring.application.name=eureka-server 

server.port=1111 

eureka.instance.hostname=peer1 

eureka.client.serviceUrl.defaultZone=http:/peer2:1112/eurekay/ 

e 创 建 application-peer2.properties， 作 为 peer2 服 务 中 心 的 配置 ， 并 将 
serviceUrl 指 癌 peer1: 

spring.application.name=eureka-server 

server.port=1112 

eureka.instance.hostname=peer2 

eureka.client.serviceUTrl.defaultZone=http://peer1:1111/eureka/ 

e 在 /etc/hosts 文件 中 添加 对 peer1 和 peer2 的 转换 ， 让 上 面 配 置 的 host 
形式 的 serviceUrl 能 在 本 地 正确 访问 到 ; Windows 系统 路 径 为 
C:\Windows\System32\drivers\etc\hosts。 

127.0.0.1 peerl 

127.0.0.1 peer2 

e 通 过 spring.profiles.active 属 性 来 分 别 启 动 peerl1 和 peer2: 

java-jar eureka-server-1.0.0.jar--spring.profiles.active=peerl 

java-jar eureka-server-1.0.0.jar--spring.profiles.active=peer2 

此 时 访问 peer1 的 注册 中 心 http://localhost:1111/， 如 下 图 所 示 ， 我 们 
可 以 看 到 ，registered-replicas 中 已 经 有 peer2 节 点 的 eureka-server 了 。 同样 
的 ， 我 们 访问 peer2 的 注册 中 心 http:Wlocalhost:1112/， 也 能 看 到 registered- 
replicas 中 己 经 有 peer1 节 点 ， 并 且 这 些 节 点 在 可 用 分 片 (available- 
replicase) 之 中 。 我 们 也 可 以 尝试 关闭 peer1， 刷 新 
http://localhost:1112/， 可 以 看 到 peer1 的 节点 变 为 了 不 可 用 分 片 


(unavailable-replicas) 。 











DS Replicas 


Instances currently registered with Eureka 


Application AMis Availiabllity Zones Status 


EUREKA-SERVER n/a (2) 2) UP (2) 
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e 在 设置 了 多 节点 的 服务 注册 中 心 之 后 ， 服 务 提 供 方 还 需要 做 一 些 简 
单 的 配置 才能 将 服务 注册 到 Eureka Server 集群 中 。 我 们 以 hello-service 
为 例 ， 修 改 application.properties 配 置 文件 ， 如 下 所 示 : 

spring.application.name=hello-service 

eureka.client.serviceUTrl.defaultZone=http://peer1:1111/eureka/,http://peer. 
2/eureka/ 

上 面 的 配置 主要 对 eureka.client.serviceUrl.defaultZone 属 性 做 了 改动 ， 
将 注册 中 心 指 癌 了 之 前 我 们 搭建 的 peer1 与 peer2。 

下 面 ， 我 们 启动 该 服务 ， 通 过 访问 http://localhost:1111/ 和 
http://localhost:1112/， 可 以 观察 到 ”hello-service ”服务 同时 被 注册 到 了 
peer1 和 peer2 上 。 若 此 时 断 开 peer1， 由 于 compute-service 同 时 也 辣 peer2 
注册 ， 因 此 在 peer2 上 的 其 他 服务 依然 能 访问 到 hello-service， 从 而 实现 
了 服务 注册 中 心 的 高 可 用 。 

如 我 们 不 想 使 用 主机 名 来 定义 注册 中 心 的 地 址 ， 也 可 以 使 用 IP 地 址 
的 形式 ， 但 是 需要 在 配置 文件 中 增加 配置 参数 eureka.instance.prefer-ip- 
address=true， 该 值 默 认为 false。 


服务 发 了 与 消 井 


通过 上 面 的 内 容 介 绍 与 实践 ， 我 们 已 经 搭建 起 微服 务 架 构 中 的 核心 
组 件 一 服务 注册 中 心 〈 包 括 单 节 点 模式 和 高 可 用 模式 ) 。 同 时 ， 还 对 上 




















一 章 中 实现 的 Spring Boot 入 门 程序 做 了 改造 。 通 过 简单 的 配置 ， 使 该 程 
序 注 册 到 Eureka 注 册 中 心 上 ， 成 为 该 服务 治理 体系 下 的 一 个 服务 ， 命 名 

为 hello-service。 现 在 我 们 已 经 有 了 服务 注册 中 心 和 服务 提供 者 ， 下 面 就 
来 尝试 构建 一 个 服务 消费 者 ， 它 主要 完成 两 个 目标 ， 发 现 服务 以 及 消费 
服务 。 其 中 ， 服 务 发 现 的 任务 由 Eureka 的 客户 端 完成 ， 而 服务 消费 的 任 

务 由 Ribbon 完 成 。Ribbon 是 一 个 基于 HTTP 和 TCP 的 客户 端 负载 均衡 

器 ， 它 可 以 在 通过 客户 端 中 配置 的 ribbonServerList 服 务 端 列表 去 轮 询 访 

问 以 达到 均衡 负载 的 作用 。 当 Ribbon 与 Eureka 联合 使 用 时 ，Ribbon 的 
服务 实例 清单 RibbonServerList 会 被 DiscoveryEnabledNIWSServerList 
重 写 ， 扩 展 成 从 “Eureka 注册 中 心中 获取 服务 端 列 表 。 同 时 它 也 会 用 
NIWSDiscoveryPing 来 取代 IPing， 它 将 职责 委托 给 Eureka 来 确定 服务 
问 是 否 已 经 启动 。 在 本 章 中 ， 我 们 对 Ribbon 不 做 详细 的 介绍 ， 访 者 只 需 
要 理解 它 在 Eureka 服 务 发 现 的 基础 上 ， 实 现 了 一 套 对 服务 实例 的 选择 策 

略 ， 从 而 实现 对 服务 的 消费 。 下 一 章 我 们 会 对 Ribbon 做 详细 的 介绍 和 分 


析 。 

下 面 我 们 通过 构建 一 个 简单 的 示例 ， 看 看 在 Eureka 的 服务 治理 体系 
下 如 何 实现 服务 的 发 现 与 消费 。 

e 首 先 ， 我 们 做 一 些 准 备 工 作 。 局 动 之 前 实现 的 服务 注册 中 心 eureka- 
server 以 及 hello-service 服 务 ， 为 了 实验 Ribbon 的 客户 端 负 载 均衡 功能 ， 
我 们 通过 java-jar 命 令 行 的 方式 来 启动 两 个 不 同 端口 的 hello-service， 具 
体 如 下 : 

java-jar hello-service-0.0.1-SNAPSHOT.jar--server.port=8081 

java-jar hello-service-0.0.1-SNAPSHOT.jar--server.port=8082 

e 在 成 功 启动 两 个 hello-service 服务 之 后 ， 如 下 图 所 示 ， 从 Eureka 信 
息 面 板 中 可 以 看 到 名 为 HELLO-SERVICE 的 服务 中 出 现 了 两 个 实例 单 
元 ， 分 别 是 通过 命令 行 启 动 的 8081 端 口 和 8082 端 口 的 服务 。 
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e 创 建 一 个 Spring Boot 的 基础 工程 来 实现 服务 消费 者 ， 取 名 为 ribbon- 
consumer， 并 在 pom.xml 中 引入 如 下 的 依赖 内 容 。 较 之 前 的 hello- 
service， 我 们 新 增 了 Ribbon 模 块 的 依赖 spring-cloud-starter-ribbon。 








<parent> 
<groupld>org.springframework.boot</grouplId> 
<artifactId>spring-boot-starter-parent</artifactId> 
<version>1.3.7.RELEASE</version> 
<relativePath/> <!-- lookup Parent from repository --> 
</parent> 


<dependencies> 
<dependency> 
<groupId>org.springframework.boot</groupId> 
<artifactId>spring-boot-starter-web</artifactId> 
</dependency> 


<dependency> 
<groupId>org.springframework.cloud</groupId> 
<artifactId>spring-cloud-starter-eureka</artifactId> 
</dependency> 


<dependency> 
<groupld>org.springframework.cloud</groupId> 
<artifactId>spring-cloud-starter-ribbon</artifactId> 
</dependency> 
</dependencies> 


<dependencyManagement> 
<dependencies> 
<dependency> 
<groupId>org.springframework.cloud</groupId> 
<artifactId>spring-cloud-dependencies</artifactId> 
<version>Brixton.SR5</version> 
<type>pom</type> 
<scope>import</scope> 
</dependency> 
</dependencies> 
</dependencyManagement> 


e 创 建 应 用 主 类 ConsumerApplication， 通 过 @EnableDiscoveryClient 注 
解 让 该 应 用 注册 为 Eureka 客 户 端 应 用 ， 以 获得 服务 发 现 的 能 力 。 同 时 ， 
在 该 主 类 中 创建 RestTemplate 的 Spring Bean 实 例 ， 并 通过 
@LoadBalanced 注 解 开 局 客户 端 负载 均衡 。 

@EnableDiscoveryClient 

@SpringBootApplication 

public class ConsumerApplication { 

Bean 

@LoadBalanced 

RestTemplate restTemplate () { 


return new RestTemplate (); 

} 

public static void main (String[Jargs) { 

SpringApplication.run (ConsumerApplication.class,args) ; 

} 

} 

e@ 创 建 ConsumerController 类 并 实现 /ribbon-consumer 接 口 。 在 该 接口 
中 ， 通 过 在 上 面 创建 的 RestTemplate 来 实现 对 HELLO-SERVICE 服务 
提供 的 /hello 接 口 进 行 调用 。 可 以 看 到 这 里 访问 的 地 址 是 服务 名 HELLO- 
SERVICE， 而 不 是 一 个 具体 的 地 址 ， 在 服务 治理 框架 中 ， 这 是 一 个 非常 
重要 的 特性 ， 也 符合 在 本 章 一 开始 对 服务 治理 的 解释 。 

(DRestController 

public class ConsumerController { 

(OAutowired 

RestTemplate restTemplate; 

@RequestMapping (value="/ribbon- 
consumer",method=RequestMethod.GET) 

public String helloConsumer () { 





return restTemplate.getForEntity ("http:/HELLO- 
SERVICE/hello",String.class) .getBody 〈) ; 

} 

} 


e 在 application.properties 中 配置 Eureka 服 务 注册 中 心 的 位 置 ， 需 要 与 
之 前 的 HELLO-SERVICE 一 样 ， 不 然 是 及 现 不 了 该 服务 的 ， 同 时 设置 该 
消费 者 的 端口 为 90000， 不 能 与 之 前 局 动 的 应 用 端口 冲突 。 

spring.application.name=ribbon-consumer 

server.port=9000 

eureka.client.serviceUTrl.defaultZone=http://localhost:1111/eureka/ 

e 局 动 ribbon-consumer 应 用 后 ， 我 们 可 以 在 Eureka 信 息 面 板 中 看 到 ， 
当前 除了 HELLO-SERVICE 之 外 ， 还 多 了 我 们 实现 的 RIBBON- 
CONSUMER 有 上 服务。 
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e 通 过 向 http://localhost:9000/ribbon-consumer 发 起 GET 请 求 ， 成 功 返 
回 了 “Hello World”。 此 时 ， 我 们 可 以 在 ribbon-consumer 应 用 的 控制 台中 


看 到 如 下 信息 ，Ribbon 输 出 了 当前 客户 并 维护 的 HELLO- ee 
务 列表 情况 。 其 中 包含 了 各 个 实例 的 位 置 ，Ribbon 就 是 按照 此 信息 进 
轮 询 访问 ， 以 实现 基于 客户 问 的 负载 均衡 。 另 外 还 输出 了 一 此 其 他 过 
有 用 的 信息 ， 如 对 各 个 实例 sr 数量 、 第 一 次 连接 信息 、 上 一 次 连 
接 信息 、 总 的 请 求 失 败 数量 

El Dna ven sil odd 
DynamicServerListLoadBalancer for client 

HELLO-SERVICE initialized: 

DynamicServerListLoadBalancer:{NFLoadBalancer:name=HELLO- 
SERVICE,current list of 

Servers=[PC-201602152056:8082,PC-201602152056:8081],Load 
balancer stats=Zone stats: 

{defaultzone=[Zone:defaultzone; Instance count:2; Active connections 
count: 0; 

Circuit breaker tripped count: 0; Active connections per server: 0.0;] 

},Server stats:[[Server:PC-201602152056:8082; Zone:defaultZone: 
Total Requests:0; 

Successive connection failure:0; Total blackout seconds:0;Last 
connection made:Thu Jan 

01 08:00:00 CST 1970; First connection made: Thu Jan 01 08:00:00 
CST 1970; Active 

Connections:0; total failure count in last (1000) msecs:0; average resp 
time:0.0; 90 

percentile resp time:0.0; 95 percentile resp time:0.0; min resp 
time:0.0; max resp 

time:0.0; stddev resp time:0.0] 

,[Server:PC-201602152056:8081; Zone:defaultZone; Total Requests:0; 
Successive 

connection failure:0; ‘Total blackout seconds:0;Last connection 
made:Thu Jan 01 08:00:00 

CST 1970; First connection made: Thu Jan 01 08:00:00 CST 1970; 
Active Connections:0; 

total failure count in last (1000) msecs:0; average resp time:0.0; 90 
percentile resp 

time:0.0; 95 percentile resp time:0.0; min resp time:0.0; max resp 
time:0.0; stddev 

resp time:0.0] 








]}ServerList:org.springframework.cloud.netflix.ribbon.eureka.DomainExt 

List@cc7240 

再 笃 试 及 送 儿 次 请 求 ， 并 观察 局 动 的 两 个 HELLO-SERVICE 的 控制 
台 ， 可 以 看 到 两 个 控制 台 会 交 伏 打印 下 面 的 日 志 ， 这 是 我 们 之 前 在 
HelloController 中 实现 的 对 服务 信息 的 输出 ， 可 以 用 来 判断 当前 ribbon- 
consumer 对 HELLO-SERVICE 的 调用 是 否 是 负载 均衡 的 。 

com.didispace.web.HelloController : /hello,host:PC- 
201602152056， 

service_id:hello-service 





Eureka 详 解 


在 上 一 节 中 ， 我 们 通过 一 个 简单 的 服务 注册 与 发 现 示 例 ， 构 建 了 
Eureka 服 务 治 理 体 系 中 的 三 个 核心 角色 : 服务 注册 中 心 、 服 务 提 供 者 以 
及 服务 消费 者 。 通 过 上 述 示 例 ， 相 信 读 者 对 于 Eureka 的 服务 治理 机 制 已 
经 有 了 一 些 初 步 的 认识 。 至 此 ， 我 们 已 经 学 会 了 如 何 构 建 服务 注册 中 心 
(包括 单 节点 和 高 可 用 部 获 ) ， 也 知道 了 如 何 使 用 Eureka 的 注解 和 配 
置 将 Spring Boot 应 用 纳入 Eureka 的 服务 治理 体系 ， 成 为 服务 提供 者 或 是 
服务 消费 者 。 同 时 ， 对 于 客户 端 负载 均衡 的 服务 消费 也 有 了 一 些 简 单 的 
接触 。 但 是 ， 在 实践 中 ， 我 们 的 系统 结构 往往 都 要 比 上 述 示例 复杂 得 
多 ， 如 果 仅 仅 依 靠 之 前 构建 的 服务 治理 内 容 ， 大 多 数 情况 是 无 法 完全 直 
接 满 足 业 务 系统 需求 的 ， 我 们 还 需要 根据 实际 情况 来 做 一 些 配置 、 调 整 
和 扩展 。 所 以 ， 在 本 节 中 ， 我 们 将 详细 介绍 Eureka 的 基础 架构 、 节 点 间 
的 通信 机 制 以 及 一 些 进 阶 的 配置 等 。 


基础 架构 


在 “服务 治理 ”一 节 中 ， 我 们 所 讲解 的 示例 虽然 简单 ， 但 是 贱 稚 虽 
。 它 已 经 包含 了 整个 Eureka 服 务 治理 基础 架构 的 三 个 核心 
要 素 。 

e 服 务 注 册 中 心 : ”Eureka 提 供 的 服务 端 ， 提 供 服务 注册 与 肥 现 的 功 
能 ， 也 惑 是 在 上 一 节 中 我 们 实现 的 eureka-server。 

e 服 务 提 供 者 : ”提供 服务 的 应 用 ， 可 以 是 Spring Boot 应 用 ， 也 可 以 
是 其 他 技术 平台 且 遵 循 Eureka 通 信 机 制 的 应 用 。 它 将 目 己 提供 的 服务 注 
册 到 Eureka， 以 供 其 他 应 用 发 现 ， 也 束 是 在 上 一 节 中 我 们 实现 的 
HELLO-SERVICE 应 用 。 

e 服 务 消费 者 : ”消费 者 应 用 从 服务 注册 中 心 获取 服务 列表 ， 从 而 使 
消费 者 可 以 知道 去 何 处 调用 其 所 需要 的 服务 ， 在 上 一 节 中 使 用 了 Ribbon 
来 实现 服务 消费 ， 另 外 后 续 还 会 介绍 使 用 Feign 的 消费 方式 。 

很 多 时 候 ， 客 户 端 既 是 服务 提供 者 也 是 服务 消费 者 。 


服 务 治 理 机 制 | 


在 体验 了 Spring Cloud Eureka 通过 简单 的 注解 配置 就 能 实现 强大 的 
服务 治理 功能 之 后 ， 我 们 来 进一步 了 解 一 下 Eureka 基 础 架构 中 各 个 元 素 














的 一 些 通信 行为 ， 以 此 来 理解 基于 Eureka 实 现 的 服务 治理 体系 是 如 何 运 
作 起 来 的 。 以 下 图 为 例 ， 其 中 有 这 样 儿 个 重要 元 素 : 
e“ 服 务 注册 中 心 -1* 和 “服务 注册 中 心 -2*”， 它 们 互相 注册 组 成 了 蜗 可 


用 集群 。 

e“ 服 务 提供 者 ”局 动 了 两 个 实例 ， 一 个 注册 到 “服务 注册 中 心 -1” 上 ， 
另外 一 个 注册 到 “服务 注册 中 心 -2 上。 

e 还 有 两 个 “服务 消费 者 ”， 它 们 也 都 分 别 只 指向 了 一 个 注册 中 心 。 





服务 提供 者 











根据 上 面 的 结构 ， 下 面 我 们 来 详细 了 解 一 下 ， 从 服务 注册 开始 到 服 
务 调用 ， 及 各 个 元 素 所 涉及 的 一 些 重 要 通信 行为 。 

服务 提供 者 

服务 注册 

“服务 提供 者 ”在 启动 的 时 候 会 通过 发 送 REST 请 求 的 方式 将 自己 注册 
到 Eureka ”Server 上 ， 同 时 带 上 了 上 自 映 服务 的 一 些 元 数据 信息 。Eureka 
Server 接 收 到 这 个 REST 请 求 之 后 ， 将 元 数据 信息 存储 在 一 个 双 层 结构 
Map 中 ， 其 中 第 一 层 的 key 是 服务 名 ， 第 二 层 的 key 是 具体 服务 的 实例 
名 。【〔 我 们 可 以 回想 一 下 之 前 在 实现 Ribbon 负 和 载 均衡 的 例子 中 ，Eureka 
言 恩 面 板 中 一 个 服务 有 多 个 实例 的 情况 ， 这 些 内 容 就 是 以 这 样 的 双 层 
Map 形 式 存 储 的 。) 

在 服务 注册 时 ， 需 要 确认 一 下 eureka.client.register-with-eureka=true 








该 值 默 认为 true。 知 设置 为 false 将 不 会 启动 注册 操作 。 
服务 同步 

如 架构 图 中 所 示 ， 这 里 的 两 个 服务 提供 者 分 别 注册 到 了 两 个 不 同 的 
服务 注册 中 心 上 ， 也 融 是 说 ， 它 们 的 信息 分 别 被 两 个 服务 注册 中 心 所 维 
护 。 此 时 ， 由 于 服务 注册 中 心 之 间 因 互相 注册 为 服务 ， 当 服务 提供 者 发 
送 注册 请 求 到 一 个 服务 注册 中 心 时 ， 它 会 将 该 请 求 转发 给 集群 中 相连 的 
其 他 注册 中 心 ， 从 而 实现 注册 中 心 之 间 的 服务 同步 。 通 过 服务 同步 ， 两 
个 服务 提供 者 的 服务 信息 就 可 以 通过 这 两 台 服 务 注册 中 心中 的 任意 一 台 
获取 到 。 

服务 续 约 

在 注册 完 服务 之 后 ， 服 务 提供 者 会 维护 一 个 心跳 用 来 持续 告诉 
Eureka Server:“ 我 还 活着 ”， 以 防止 Eureka Server 的 “剔除 任务 2 将 该 服务 
实例 从 服务 列表 中 排除 出 去 ， 我 们 称 该 操作 为 服务 续 约 (Renew) 。 
关于 服务 续 约 有 两 个 重要 属性 ， 我 们 可 以 关注 并 根据 需要 来 进行 调 


整 





eureka.instance.lease-renewal-interval-in-seconds=30 

eureka.instance.lease-expiration-duration-in-seconds=90 

eureka.instance.lease-renewal-interval-in-seconds 参数 用 于 定义 服务 续 
约 任务 的 调用 间隔 时 间 ， 默 认为 30 秒 。eureka.instance.lease- 
expirationduration-in-seconds 参 数 用 于 定义 服务 失效 的 时 间 ， 默 认为 90 
秒 。 

服务 消费 者 

获取 服务 

到 这 里 ， 在 服务 注册 中 心 已 经 注册 了 一 个 服务 ， 并 且 该 服务 有 两 个 
实例 。 当 我 们 启动 服务 消费 者 的 时 候 ， 它 会 发 送 一 个 REST 请 求 给 服务 
注册 中 心 ， 来 获取 上 面 注 册 的 服务 清单 。 为 了 性 能 考虑 ，Eureka Server 
会 维护 一 份 只 读 的 服务 清单 来 返回 给 客户 端 ， 同 时 该 缓存 清单 会 每 隔 30 
秒 更 新 一 次 。 

获取 服务 是 服务 消费 者 的 基础 ， 所 以 必须 确保 eureka.client.fetch- 
registry=true 参 数 没 有 被 修改 成 false， 该 值 默认 为 tue。 若 希望 修改 缓存 
清单 的 更 新 时 间 ， 可 以 通过 eureka.client.registry-fetch-interval- 
seconds=30 参 数 进行 修改 ， 该 参数 默认 值 为 30， 单 位 为 秒 。 

服务 调用 

服务 消费 者 在 获取 服务 清单 后 ， 通 过 服务 名 可 以 获得 具体 提供 服务 
的 实例 名 和 该 实例 的 元 数据 信息 。 因 为 有 这 些 服 务实 例 的 详细 信息 ， 所 
以 客户 端 可 以 根据 自己 的 需要 决定 具体 调用 哪个 实例 ， 在 Ribbon 中 会 默 
认 采 用 轮 询 的 方式 进行 调用 ， 从 而 实现 客户 端的 负载 均衡 。 




















对 于 访问 实例 的 选择 ，Eureka 中 有 Region 和 Zone 的 概念 ， 一 个 Region 
中 可 以 包含 多 个 Zone， 每 个 服务 客户 器 需要 被 注册 到 一 个 Zone 中 ， 所 以 
每 个 客户 端 对 应 一 个 Region 和 一 个 Zone。 在 进行 服务 调用 的 时 候 ， 优 先 
访问 同 处 一 个 ”Zone ”中 的 服务 提供 方 ， 知 访问 不 到 ， 就 访问 其 他 的 
J 更 多 关于 Region 和 Zone 的 知识 ， 我 们 会 在 后 续 的 源码 解读 中 介 
y 


服务 下 线 

在 系统 运行 过 程 中 必然 会 面临 关闭 或 重启 服务 的 某 个 实例 的 情况 ， 
在 服务 关闭 期 间 ， 我 们 自然 不 希望 客户 端 会 继续 调用 关闭 了 的 实例 。 所 
以 在 客户 端 程序 中 ， 当 服务 实例 进行 正常 的 关闭 操作 时 ， 它 会 触发 一 个 
服务 下 线 的 REST 请 求 给 Eureka Server， 告 诉 服务 注册 中 心 : “我 要 下 线 
了 ”。 服 务 端 在 接收 到 请 求 之 后 ， 将 该 服务 状态 置 为 下 线 (DOWN ) ， 
并 把 该 下 线 事件 传播 出 去 。 

服务 注册 中 心 

失效 剔除 

有 些 时候 ， 我 们 的 服务 实例 并 不 一 定 会 正常 下 线 ， 可 能 由 于 内 存 溢 
出 、 网 络 故 障 等 原因 使 得 服务 不 能 正常 工作 ， 而 服务 注册 中 心 并 未 收 
到 “服务 下 线 ” 的 请 求 。 为 了 从 服务 列表 中 将 这 些 无 法 提供 服务 的 实例 易 
除 ，Eureka Server 在 局 动 的 时 候 会 创建 一 个 定时 任务 ， 默 认 每 隔 一 段 时 
Se 将 当前 清单 中 超时 (默认 为 90 秒 ) 没有 续 约 的 服务 易 
除 人 

自我 保护 

当 我 们 在 本 地 调试 基于 Eureka 的 程序 时 ， 基 本 上 都 会 们 到 这 样 一 个 
问题 ， 在 服务 注册 中 心 的 信息 面板 中 出 现 类 似 下 面 的 红色 警告 信息 : 

EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING 
INSTANCES ARE UP WHEN THEY'RE NOT.RENEWALS ARE LESSER 
THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING 
EXPIRED JUST TO BE SAFE. 

实际 上 ， 该 警告 就 是 触发 了 Eureka Server 的 自我 保护 机 制 。 之 前 我 们 
介绍 过 ， 服 务 注 册 到 Eureka ” Server 之后， 会 维护 一 个 心跳 连接 ， 告 诉 
Eureka Server 自己 还 活着 。Eureka Server 在 运行 期 间 ， 会 统计 心跳 失败 
的 比例 在 15 分 钟 之 内 是 否 低 于 85%， 如 果 出 现 低 于 的 情况 (在 单机 调试 
的 时 候 很 容易 满足 ， 实 际 在 生产 环境 上 通常 是 由 于 网 络 不 稳定 导 
致 ) ,Eureka Server 会 将 当前 的 实例 注册 信息 保护 起 来 ， 让 这 些 实例 不 会 
过 期 ， 尽 可 能 保护 这 些 注 册 人 信息。 但 是 ， 在 这 段 保护 期 间 内 实例 知 出 现 
问题 ， 那 么 客户 端 很 容易 拿 到 实际 已 经 不 存在 的 服务 实例 ， 会 出 现 调用 
失败 的 情况 ， 所 以 客户 端 必须 要 有 容错 机 制 ， 比 如 可 以 使 用 请 求 重 试 、 

















斯 路 吉 等 机 制 。 

由 于 本 地 调试 很 容易 触发 注册 中 心 的 保护 机 制 ， 这 会 使 得 注册 中 心 
维护 的 服务 实例 不 那么 准确 。 所 以 ， 我 们 在 本 地 进行 开发 的 时 候 ， 可 以 
使 用 eureka.server.enableself-preservation=false 参 数 来 关闭 保护 机 制 ， 以 
确保 注册 中 心 可 以 将 不 可 用 的 实例 正确 剔除 。 


源码 分 析 


上 面 ， 我 们 对 Eureka 中 各 个 核心 元 素 的 通信 行为 做 了 详细 的 介绍 ， 
相信 大 家 已 经 对 Eureka 的 运行 机 制 有 了 一 定 的 了 解 。 为 了 更 深入 地 理解 
[a . 运作 和 配置 ， 下 面 我 们 结合 源码 来 分 别 看 看 各 个 通信 行为 是 如 何 实 
现 的 。 

在 看 具体 源码 之 前 ， 我 们 先 回顾 一 下 之 前 所 实现 的 内 容 ， 从 而 找到 
一 个 合适 的 切入 口 去 分 析 。 首 先 ， 对 于 服务 注册 中 心 、 服 务 提供 者 、 服 
务 消 费 者 这 三 个 主要 元 素来 说 ， 后 两 者 〈 也 就 是 Eureka 客 户 端 ) 在 整个 
运行 机 制 中 是 大 部 分 通信 行为 的 主动 发 起 者 ， 而 注册 中 心 主要 是 处 理 请 
求 的 接收 者 。 所 以 ， 我 们 可 以 从 Eureka 的 客户 端 作为 入 口 看 看 它 是 如 何 
完成 这 些 主动 通信 行为 的 。 

我 们 在 将 一 个 普通 的 Spring ”Boot 应 用 注册 到 Eureka Server 或 是 从 
Eureka Server 中 获取 服务 列表 时 ， 主 要 就 做 了 两 件 事 : 

e 在 应 用 主 类 中 配置 了 @EnableDiscoveryClient 注 解 。 

e 在 application.properties 中 用 eureka.client.serviceUrl.defaultZone 

参数 指定 了 服务 注册 中 心 的 位 置 。 

顺 着 上 面 的 线索 ， 我 们 来 看 看 @EnableDiscoveryClient 的 源码 ， 有 具体 
如 下 : 

@Target (ElementType.TYPE) 

@Retention (RetentionPolicy.RUNTIME) 
Documented 

QInherited 

@Import 〈EnableDiscoveryClientImportSelector.class ) 
public COinterface EnableDiscoveryClient { 





} 

从 该 注解 的 注释 中 我 们 可 以 知道 ， 它 主要 用 来 开启 DiscoveryClient 的 
实例 。 通 过 搜索 DiscoveryClient， 我 们 可 以 发 现 有 一 个 类 和 一 个 接口 。 
通过 梳理 可 以 得 到 如 下 图 所 示 的 关系 : 





1 LookupService 
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(1 DiscoveryClient LE EurekaClient 
T 下 
人 
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其 中 在 这 的 


org.Springframework.cloud.client.discovery.DiscoveryClient 是 Spring Cloud 
的 接口 ， 它 定义 了 用 来 发 现 服务 的 常用 抽象 方法 ， 通 过 该 接口 可 以 有 效 
地 屏蔽 服务 治理 的 实现 细节 ， 所 以 使 用 Spring ” ”Cloud 构建 的 微服 务 应 用 
可 以 方便 地 切换 不 同 服务 治理 框架 ， 而 不 改动 程序 代码 ， 只 需要 另外 添 
加 一 些 针 对 服务 治理 框架 的 配置 即 可 。 
org.springframework.cloud.netflix.eureka.EurekaDiscoveryClient 是 对 该 接 
口 的 实现 ， 从 命名 来 判断 ， 它 实现 的 是 对 Eureka 发 现 服 务 的 封装 。 所 
以 EurekaDiscoveryClient 依赖 了 Netflix Eureka 的 
com.netflix.discovery.EurekaClient 接 口 ，EurekaClient 继 承 了 
LookupService 接 口 ， 它 们 都 是 Netflix 开 源 包 中 的 内 容 ， 主 要 定义 了 针对 
Eureka 的 发 现 服务 的 抽象 方法 ， 而 真正 实现 发 现 服务 的 则 是 Netflix 包 中 
的 com.netflix.discovery.DiscoveryClient 类 。 

接 下 来 ， 我 们 就 来 详细 看 看 DiscoveryClient 类 吧 。 先 解读 一 下 该 类 头 
部 的 注释 ， 注 释 的 大 致 内 容 如 下 所 未 : 

这 个 类 用 于 帮助 与 Eureka Server 互 相 协 作 。 

Eureka Client 负 责 下 面 的 任务 : 

- 问 Eureka Server 注 册 服 务实 例 

- 问 Eureka Server 服 务 租约 

- 当 服 务 关 闭 期 间 ， 癌 Eureka Server 取 消 租约 

-查询 Eureka Server 中 的 服务 实例 列表 

Eureka Client 还 需要 配置 一 个 Eureka Server 的 URL 列 表 。 

在 具体 研究 Eureka Client 负 责 完 成 的 任务 之 前 ， 我 们 先 看 看 在 哪里 对 
Eureka Server 的 URL 列 表 进 行 配置 。 根 据 我 们 配置 的 属性 名 
eureka.client.serviceUrl.defaultZone， 通 过 serviceUrl 可 以 找到 该 属性 相 
关 的 加 载 属 性 ， 但 是 在 “SR5 版 本 中 它们 都 被 @Deprecated 标 注 为 不 再 建 
议 使 用 ， 并 @link 到 了 替代 类 














com.netflix.discovery.endpoint.EndpointUtils， 所 以 我 们 可 以 在 该 类 中 找 
到 下 面 这 个 函数 : 
public static Map<String,List<String>> 
getServiceUrlsMapFromConfig 
EurekaClientConfig clientConfig, String instanceZone,boolean 
preferSameZone) { 
Map<String,List<String>> orderedUrls=new LinkedHashMap<> (); 
String region=getRegion (clientConfig) ; 
String[lavailZones=clientConfig.getAvailabilityZones (clientConfig.getR 
if (availZones==null || availZones.length==0) { 
availZones=new String[1]; 
availZones[0]=DEFAULT_ZONE:; 


int 
myZoneOffset=getZoneOffset (instanceZone,preferSameZone,availZones) ; 
String zone=availZones[myZoneOffset]; 
List<String> 
serviceUTrls=clientConfig.getEurekaServerServiceUrls (zone); 
if (serviceUrls !=null ) { 
orderedUrls.put (zone,serviceUrls) ; 


ctr orderedUrls; 

} 

Region、Zone 

在 上 面 的 函数 中 ， 可 以 有 发现 ， 客 户 端 依次 加 载 了 两 个 和 内容， 第 一 个 
是 Region， 第 二 个 是 Zone， 从 其 加 载 逻 辑 上 我 们 可 以 判断 它们 之 间 的 关 


系 : 
e 通 过 getRegion 函 数 ， 我 们 可 以 看 到 它 从 配置 中 读 取 了 一 个 Region 返 
回 ， 所 以 一 个 微服 务 应 用 只 可 以 属于 一 个 Region， 如 采 不 特别 配置 ， 默 
认为 default。 知 我 们 要 自己 设置 ， 可 以 通过 eureka.client.region 属 性 来 定 
public static String getRegion (EurekaClientConfig clientConfig) { 
String region=clientConfig.getRegion (); 
if (region==null) { 
region=DEFAULT_ REGION; 


region=region.trim () .toLowerCase 〈) ; 

return region; 

} 

e 通 过 getAvailabilityZones 函数 ， 可 以 知道 当 我 们 没有 特别 为 Region 
配置 Zone 的 时 候 ， 将 默认 采用 defaultZone， 这 也 是 我 们 之 前 配置 参数 
eureka.client.serviceUrl.defaultZone 的 由 来 。 奋 要 为 应 用 指定 Zone， 可 以 
通过 eureka.client.availability-zones 属 性 来 进行 设置 。 从 该 函数 的 returmn 内 
容 ， 我 们 可 以 知道 Zone 能 够 设置 多 个 ， 并 且 通 过 逗号 分 阳 来 配置 。 由 
此 ， 我 们 可 以 判断 Region 与 Zone 是 一 对 多 的 关系 。 

public String[]jgetAvailabilityZones (String region ) { 

String value=this.availabilityZones.get (region) ; 

if (value==null) { 

value=DEFAULT_ZONE. 

} 

return value.split (",") ; 

} 

serviceUrls 

在 获取 了 Region 和 Zone 的 信息 之 后 ， 才 开始 真正 加 载 Eureka Server 的 
具体 地 址 。 它 根据 传 入 的 参数 按 一 定 算法 确定 加 载 位 于 哪 一 个 Zone 配置 
的 serviceUrls。 

int 
myZoneOffset=getZoneOffset (instanceZone,preferSameZone,availZones) ; 

String zone=availZones[myZoneOffset]; 

List<String> 
serviceUrls=clientConfig.getEurekaServerServiceUrls (zone); 

具体 获取 serviceUrls 的 实现 ， 我 们 可 以 详细 查看 
getEurekaServerServiceUrls 函 数 的 具体 实现 类 EurekaClientConfigBean， 
该 类 是 EurekaClientConfig 和 EurekaConstants 接 口 的 实现 ， 用 来 加 载 配 
置 文件 中 的 内 容 ， 这 里 有 非常 多 有 用 的 信息 ， 我 们 先 说 一 下 此 处 我 们 关 
心 的 ， 关 于 defaultZone 的 信息 。 通 过 搜索 defaultZone， 我 们 可 以 很 容易 
找到 下 面 这 个 函数 ， 它 具体 实现 了 如 何 解析 该 参数 的 过 程 ， 通 过 此 内 
容 ， 我 们 就 可 以 知道 ，eureka.client.serviceUrl.defaultZone 属性 可 以 配置 
多 个 ， 并 且 需 要 通过 去 号 分 隔 。 











public List<String> getEurekaServerServiceUrls (String my2one) 1{ 

String serviceUrls = this.serviceUr] .get (myZone); 

if (serviceUrls == null || serviceUrls.isEmpty()) { 
serviceUrls = this.serviceUr] .get (DEFAULT 2ZONE); 

} 

if (!StringUtils.isEmpty(serviceUrls)) 1 
final String[] serviceUrlsSplit = 

StringUtils.commaDelimitedListToStringArray (serviceUrls); 


List<String> eurekaServiceUrls = new ArrayList<>(serviceUrlsSplit.length); 
for (String eurekaServiceUr]1l : serviceUrlsSplit) { 
if (lIendsWithSlash (eurekaServiceUr1l)) I 
eurekaServiceUr] += "/"; 
} 
eurekaServiceUrls.add (eurekaServiceUr1); 


} 


return eurekaServiceUrls; 
} 
return new ArrayList<>(); 


) 

当 我 们 在 微服 务 应 用 中 使 用 Ribbon 来 实现 服务 调用 时 ， 对 于 Zone 的 
设置 可 以 在 负载 均衡 时 实现 区 域 灯 和 特性 : Ribbon 的 默认 策略 会 优先 访 
问 同 客户 端 处 于 一 个 Zone 中 的 服务 端 实例 ， 只 有 当 同 一 个 Zone 中 没有 
可 用 服务 问 实 例 的 时 候 才 会 访问 其 他 Zone 中 的 实例 。 所 以 通过 Zone 属性 
的 定义 ， 配 合 实际 部 闭 的 物理 结构 ， 我 们 就 可 以 有 效 地 设计 出 对 区 域 性 
故障 的 容错 集群 。 

服务 注册 

在 理解 了 多 个 服务 注册 中 心 信 息 的 加 载 后 ， 我 们 再 回头 看 看 
DiscoveryClient 类 是 如 何 实现 “服务 注册 ”行为 的 ， 通 过 查看 它 的 构造 
类 ， 可 以 找到 它 调 用 了 下 面 这 个 函数 : 


private void initScheduledTasks () I 
if (clientConfig.shouldRegisterWithEureka()) { 


// InstanceInfo replicator 

instanceInfoReplicator = new InstanceInfoReplicator!( 
this, 
instanceInfo, 
clientConfig.getInstanceInfoReplicationIntervalSeconds () ， 
2 A DurstSize 


instanceInfoReplicator.start (clientConfig.getIinitialInstanceInfoReplicationIinterval 
Seconds ())，} 


} else { 
logger.info("Not registering with Eureka server Per configuration"); 


} 


} 
从 上 面 的 函数 中 ， 可 以 看 到 一 个 与 服务 注册 相关 的 判断 语句 

if (clientConfig.shouldRegisterWithEureka() ) 。 在 该 分 支 内 ， 创 建 了 

一 个 ”InstanceInfoReplicator 类 的 实例 ， 它 会 执行 一 个 定时 任务 ， 而 这 个 

定时 任务 的 具体 工作 可 以 查看 该 类 的 rn《〈) 函数 ， 具 体 如 下 所 示 : 


RablaecyoiaQan (人 4 
try { 
discoveryClient .refreshInstanceInfo()， 





Long dirtyTimestamp = instanceInfo.isDiztymwithTime()， 
if (dirtyTimestamp != null) 1 
discoveryClient.register(); 
instanceInfo.unsetIsDirty(dirtyTimestamp); 
} 
} catch (Throwable 七 ) { 
logger.warn("There was a Problem with the instance info replicator", t); 
HeinadLe 
Future next = Scheduler.schedule (this, replicationIntervalSeconds, 
TimeUnit .SECONDS); 


scheduledPeriodicRef.set (next); 


} 


} 
相信 大 家 都 发 现 了 discoveryClient.register () ; 这 一 行 ， 真 正 触发 调 
用 注册 的 地 方 就 在 这 里 。 继 续 查 看 register 〈) 的 实现 内 容 ， 如 下 所 示 : 








boolean register() throws Throwable { 
logger.info (PREFIX + apPPathIaentifier + ": registering service..."); 
EurekaHttpResponse<Void> httpResponse; 
1 
httpResponse = eurekaTransport.registrationClient.register(instanceInfo); 
} catch (Exception e) 1{ 
logger.warn("{} - registration failed {}", PREFIX + apPPathIQentifier， 
e.getMessage()s,: ee)? 
throw e; 
} 
if (logger.isIinfoEnabled()) 1 
logger.info("{} - registration status: {}", PREFIX + appPathIidentifier, 
httpResponse.getSstatusCode()); 


} 
return httpResponse.getStatusCode() == 204; 


} 

通过 属性 命名 ， 大 家 基本 也 能 猜 出 来 ， 注 册 操 作 也 是 通过 REST 请 
求 的 方式 进行 的 。 同 时 ， 我 们 能 看 到 发 起 注册 请 求 的 时 候 ， 传 入 了 一 个 
com.netflix.appinfo.InstanceInfo 对 象 ， 该 对 象 就 是 注册 时 客户 端 给 服务 妆 
的 服务 的 元 数据 。 

服务 获取 与 服务 续 约 

顺 着 上 面 的 思路 ， 我 们 继续 来 看 DiscoveryClient 的 initScheduledTasks 
， 不 难 发 现在 其 中 还 有 两 个 定时 任务 ， 分 别 是 “服务 获取 ”和 “服务 
续 丝 ”; 

private void initScheduledTasks () { 

if (clientConfig.shouldFetchRegistry () ) { 

//registry cache refresh timer 

int 
registryFetchIntervalSeconds=clientConfig.getRegistryFetchIntervalSeconds 

int 
expBackOffBound=clientConfig.getCacheRefreshExecutorExponentialBackC 

scheduler.schedule 《 

new TimedSupervisorTask ( 

"cacheRefresh", 

scheduler, 

cacheRefreshExecutor， 

registryFetchIntervalSeconds, 

TimeUnit.SECONDS， 

expBackOffBound, 

new CacheRefreshThread () 

3 


registryFetchIntervalSeconds,TimeUnit.SECONDS) ; 

}if (clientConfig.shouldRegisterWithEureka () ) { 

int 
renewalIntervalInSecs=instanceInfo.getLeaseInfo () .getRenewalIntervalIns 

int 
expBackOffBound=dlientConfig.getHeartbeatExecutorExponentialBackOffB. 

logger.info ("Starting heartbeat executor: "+"renew interval iis: 
"+renewalIntervalInSecs ) ; 

/Heartbeat timer 

scheduler.schedule 《 

new TimedSupervisorTask ( 

"heartbeat", 

scheduler, 

heartbeatExecutor, 

renewalIntervalInSecs， 

TimeUnit.SECONDS, 

expBackOffBound, 

new HeartbeatThread () 

2 

renewalIntervalInSecs,TimeUnit.SECONDS ) ; 

/InstanceInfo replicator 


从 源码 中 我 们 可 以 发 现 , “服务 获取 ”任务 相对 于 “服务 续 约 ”和 “服务 
注册 ”任务 更 为 独立 。“ 服 务 续 约 ”与 “服务 注册 ”在 同一 个 if 迎 辑 中 ， 这 个 
不 难 理解 ， 服 务 注册 到 Eureka Server 后 ， 自 然 需 要 一 个 心跳 去 续 约 ， 防 
止 被 剔除 ， 所 以 它们 肯定 是 成 对 出 现 的。 从 源码 中 ， 我 们 更 清楚 地 看 到 
了 之 前 所 提 到 的 ， 对 于 服务 续 约 相关 的 时 间 控 制 参 数 : 

eureka.instance.lease-renewal-interval-in-seconds=30 

eureka.instance.lease-expiration-duration-in-seconds=90 

而 “服务 获取 ”的 逻辑 在 独立 的 一 个 让 判断 中 ， 其 判断 依据 就 是 我 们 
之 前 所 提 到 的 eureka.client.fetch-registry=true 参数 ， 它 默认 为 tue， 大 部 
分 情况 下 我 们 不 需要 天 心 。 为 了 定期 更 新 客 己 端的 服务 清单 ， 以 保证 客 

户 闻 能 够 访问 确实 健康 的 服务 实例 ,， “服务 获取 ”的 请 求 不 会 只 限于 服务 
局 动 ， 而 是 一 个 定时 执行 的 任务 ， 从 源码 中 我 们 可 以 看 到 任务 运行 中 的 
registryFetchIntervalSeconds 参 数 对 应 的 就 是 之 前 所 提 到 的 





eureka.client.registry-fetch-interval-seconds=30 配 置 参数 ， 它 默认 为 30 
秒 。 

继续 向 下 深入 ， 我 们 能 分 别 发 现实 现 “ 服 务 获取 ”和 “服务 续 约 ”的 具 
体 方 法 ， 其 中 “服务 续 约 ”的 实现 较为 简单 ， 直 接 以 REST 请 求 的 方式 进 
行 续 约 : 

boolean renew () { 

EurekaHttpResponse<InstanceInfo>httpResponse; 


try { 
httpResponse=eurekaTransport.registrationClient.sendHeartBeat (instanc 
logger.debug ("{}-Heartbeat status: 


{}",PREFIX+appPathIldentifier,httpResponse.getStatusCode () ) ; 
if (httpResponse.getStatusCode () ==404) { 
REREGISTER_COUNTER.increment (); 
logger.info ("{}-Re-registering 

apps/{}",PREFIX+appPathIdentifier,instanceInfo.getAppName () ) ; 
return register 〈《) ; 

} 

returnhttpResponse.getStatusCode () ==200; 

} catch (Throwable e) { 

logger.error ("{}-was unable to send heartbeat! 

",PREFIX+appPathIdentifier,e ) ; 
return false; 


} 


} 

而 “服务 获取 ” 则 复杂 一 些 ， 会 根据 是 否 是 第 一 次 获取 发 起 不 同 的 
REST 请 求 和 相应 的 处 理 。 具 体 的 实现 逻辑 跟 之 前 类 似 ， 有 兴趣 的 读者 
可 以 继续 查看 服务 客户 端的 其 他 具体 内 容 ， 以 了 解 更 多 细节 。 

服务 注册 中 心 处 理 

通过 上 面 的 源码 分 析 ， 可 以 看 到 所 有 的 交互 都 是 通过 REST 请 求 来 
发 起 的 。 下 面 我 们 来 看 看 服务 注册 中 心 对 这 些 请 求 的 处 理 。Eureka 
Server 对 于 各 类 REST 请 求 的 定义 都 位 于 com.netflix.eureka.resources 包 
下 

以 “服务 注册 ”请 求 为 例 : 

@POST 

@Consumes ({"application/json","application/xml"}) 

public Response addInstance (InstancelInfo info, 

@HeaderParam (PeerEurekaNode.HEADER REPLICATION) String 








isReplication ) { 

logger.debug ("Registering instance {} (replication= 
{}) "info.getId〈) ， 

isReplication ) ; 

/validate that the instanceinfo contains all the necessary required fields 


/handle cases where clients may be registering with bad DataCenterInfo 
with missing data 

DataCenterInfo dataCenterInfo=info.getDataCenterInfo () ; 

if (dataCenterInfo instanceof UniqueIdentifier ) { 

String dataCenterInfold= ( (Uniqueldentifier) 
dataCenterInfo) .getId〈) ; 

if (isBlank (dataCenterInfoId) ) { 

boolean experimental="true".equalsIgnoreCase ( 

serverConfig.getExperimental ("registration.validation. 

dataCenterInfoId") ) ; 

if (experimental) { 

String entity="DataCenterInfo of type "+dataCenterInfo.getClass () +" 
must contain a valid id"; 

return Response.status (400) .entity (entity) .build (); 

} else if (dataCenterInfo instanceof AmazonInfo ) { 

AmazonInfo amazonInfo= (AmazonInfo ) dataCenterInfo: 

String 
effectiveId=amazonInfo.get (AmazonInfo.MetaDataKey.instanceId) ; 

if (effectiveId==null) { 

amazonInfo.getMetadata () .put ( 

AmazonInfo.MetaDataKey.instanceId.getName () ,info.getIld () ) ; 

} 

} else { 

logger.warn ("Registering DataCenterInfo of type {} without an 

appropriate id", 

dataCenterInfo.getClass () ) ; 

} 

} 

} 

registry.register (info,"true".equals (isReplication) ) ; 

return Response.status (204) .build () ; //204 to be backwards 


compatible 


} 

在 对 注册 信息 进行 了 一 堆 校 验 之 后 ， 会 调用 
org.Springframework.cloud.netflix.eureka.server.InstanceRegistry 对 象 中 的 
register (InstanceInfo info,int leaseDuration,boolean isReplication ) 函数 来 
进行 服务 注册 : 

public void register (InstanceInfo info,int leaseDuration,boolean 
isReplication) { 

if (log.isDebugEnabled () ) { 

log.debug ("register "+info.getAppName () +",vip 
"+info.getVIPAddress () 

+",leaseDuration "+leaseDuration+",isReplication " 

+isReplication ) ; 


this.ctxt.publishEvent (new EurekalnstanceRegisteredEvent (this,info, 
leaseDuration,isReplication) ) ; 
super.register (info,leaseDuration,isReplication ) ; 


} 

在 注册 函数 中 ， 先 调用 publishEvent 函数 ， 将 该 新 服务 注册 的 事件 
传播 出 去 ， 然 后 调用 com.netflix.eureka.registry.AbstractInstanceRegistry 
父 类 中 的 注册 实现 ， 将 InstanceInfo 中 的 元 数据 信息 存储 在 一 个 
ConcurrentHashMap 对 象 中 。 正 如 我 们 之 前 所 说 的 ， 注 册 中 心 存 储 了 两 
层 Map 结构 ， 第 一 层 的 key 存储 服务 名 : InstanceInfo 中 的 appName 属 
性 ， 第 二 层 的 key 存 储 实例 名 : ImstanceInfo 中 的 instanceId 属 性 。 

服务 端的 请 求 和 接收 非常 类 似 ， 对 于 其 他 的 服务 端 处 理 ， 这 里 不 再 
展开 叙述 ， 读 者 可 以 根据 上 面 的 脉络 来 自己 查看 其 内 容 (这 里 包含 很 多 
细节 内 容 ) 来 帮助 和 加 深 理 解 。 





本 0 兽 详 解 


在 分 析 了 Eureka 的 部 分 源码 之 后 ， 相 信 大 家 对 Eureka 的 服务 治理 机 
制 己 经 有 了 进一步 的 理解 。 在 本 市 中 ,我们 从 使 用 的 角度 对 Eureka 中 一 
些 常 用 配置 内 容 进行 详细 的 介绍 ， 以 帮助 我 们 根据 自身 环境 与 业务 特点 
来 进行 个 性 化 的 配置 调整 。 

在 Eureka 的 服务 治理 体系 中 ， 主 要 分 为 服务 端 与 客户 端 两 个 不 同 的 
角色 ， 服 务 端 为 服务 注册 中 心 ， 而 客户 问 为 各 个 提供 接口 的 微服 务 应 
用 。 当 我 们 构建 了 高 可 用 的 注册 中 心 之 后 ， 该 集群 中 所 有 的 微服 务 应 用 
和 后 续 将 要 介绍 的 一 些 基础 类 应 用 (如 配置 中 心 、API 网 关 等 ) 都 可 以 
视 作 该 体系 下 的 一 个 微服 务 (Eureka 客 户 端 ) 。 服 务 注册 中 心 也 一 样 ， 
只 是 高 可 用 环境 下 的 服务 注册 中 心 除 了 作为 客户 端 之 外 ， 还 为 集群 中 的 
其 他 客户 端 提供 了 服务 注册 的 特殊 功能 。 所 以 ，Eureka 客 户 端的 配置 对 
象 存在 于 所 有 Eureka 服 务 治理 体系 下 的 应 用 实例 中 。 在 实际 使 用 Spring 
Cloud Eureka 的 过 程 中 ， 我 们 所 做 的 配置 内 容 几乎 都 是 对 Eureka 客 户 端 
ee 
了 助 。 

Eureka 客 户 问 的 配置 主要 分 为 以 下 两 个 方面 。 

e 服 务 注册 相关 的 配置 信息 ， 包 括 服务 注册 中 心 的 地 址 、 服 务 获取 的 
间隔 时 间 、 可 用 区 域 等 。 

e 服 务实 例 相 关 的 配置 信息 ， 包 括 服 务实 例 的 名 称 、IP 地 址 、 端 口 
号 、 健 康 检查 路 径 等 。 

而 Eureka 服 务 端 更 多 地 类 似 于 一 个 现成 产品 ， 大 多 数 情 况 下 ， 我 们 
不 需要 修改 它 的 配置 信息 。 所 以 在 本 书 中 ， 我 们 对 此 不 进行 过 多 的 介 
绍 ， 有 兴趣 的 读者 可 以 查看 
org.springframework.cloud.netflix.eureka.server.EurekaServerConfigBean 类 
的 定义 来 做 进一步 的 学 习 ， 这 些 参 数 均 以 eureka.server 作 为 前 级 。 男 外 
值得 一 提 的 是 ， 我 们 在 学 习 本 书 内 容 进 行 本 地 调试 的 时 候 ， 可 以 通过 设 
置 该 类 中 的 enableSelfPreservation 参 数 来 天 闭 注册 中 心 的 “自我 保护 ” 功 
能 ， 以 防止 关闭 的 实例 无 法 被 服务 注册 中 心田 除 的 问题 ， 这 一 点 我 们 
在 “服务 治理 机 制 * 一 节 中 也 有 所 介绍 。 


服务 注册 类 配置 
关于 服务 注册 类 的 配置 信息 ， 我 们 可 以 通过 查看 




















人 的 源码 
来 获得 比 官方 文档 中 更 为 详尽 的 内 容 ， 这 些 配置 信息 部 以 eureka.client 为 
前 级 。 下 面 我 们 针对 一 些 第 用 的 配置 信息 做 进一步 的 介绍 和 说 明 。 

指 旨 定 注册 中 心 

在 本 章 第 1 市 的 示例 中 ， 我 们 演示 了 如 何 将 一 个 Spring Boot 应 用 纳入 
Eureka 的 服务 治理 体系 ， 除 了 引入 Eureka 的 依赖 之 外 ， 就 是 在 配置 文件 
中 指定 注册 中 心 ， 主 要 通过 eureka.client.serviceUrl 参数 实现 。 该 参数 的 
定义 如 下 所 示 ， 它 的 配置 值 存 储 在 HashMap 类 型 中 ， 并 且 设 置 有 一 组 默 
认 值 ， 默 认 值 的 key 为 defaultZone、value 为 
http://localhost:8761/eureka/。 

private Map<String,String> serviceUrl=new Hash Map<> 〈) ; 

{ 

this.serviceUrl.put (DEFAULT_ZONE,DEFAULT_URL ) ; 

} 

public static final String 
DEFAULT_URL="http://localhost:8761"+DEFAULT_PREFIX+"/"; 

public static final String DEFAULT_ZONE= defaujtZone ; 

由 于 之 前 实现 的 服务 注册 中 心 使 用 了 1111 端 口 ， 所 以 我 们 做 了 如 下 
配置 ， 来 将 应 用 注册 到 对 应 的 Eureka 服 务 端 中 。 

eureka.client.serviceUTrl.defaultZone=http://localhost:1111/eureka/ 

当 构 建 了 高 可 用 的 服务 注册 中 心 集群 时 ， 我 们 可 以 为 参数 的 value 值 
配置 多 个 注册 中 心 的 地 址 (通过 喜 写 分 阳 ) 。 比 如 下 面 的 例子 : 

eureka.client.serviceUTrl.defaultZone=http://peer1:1111/eureka/,http://peer 
2/eureka/ 

男 外 ， 为 了 服务 注册 中 心 的 安全 考虑 ， 0 
册 中 心 加 入 安全 校 验 。 这 个 时 候 ， 在 配置 serviceUrl 时 ， 需 要 在 value 值 
的 URL 中 加 入 相应 的 安全 校 验 信息 ， 比 如 http:// a 
<password>@localhost:1111/eureka。 其 中 ，<usemame> 为 安全 校 验 信息 
的 用 户 名 ，<password> 为 该 用 户 的 密码 。 

其 他 配置 

下 面 整理 了 
org.springframework.cloud.netflix.eureka.EurekaClientConfigBean 中 定义 
第 用 配置 参数 以 及 对 应 的 说 明和 默认 值 ， 这 些 参数 均 以 eureka.client 

朋 缀 前 绥 。 














参数 名 说 明 








enabled 启用 Eureka 客户 端 


续 表 


registryFetchIntervalSeconds 从 Eureka 服务 端 获取 注册 信息 的 间 隅 时间， 
单位 为 秒 


instanceInfoReplicationIntervalSeconds 更 新 实例 信息 的 变化 到 Eureka 服务 端的 间隔 
时 间 ， 单 位 为 秒 


initialInstanceInfoReplicationIntervalSeconds 初始 化 实例 信息 到 Eureka 服务 端的 间隔 时 到 | 
间 ， 单 位 为 秒 
eurekaServiceUrlPollIntervalSeconds 轮 询 Eureka 服务 端 地址 更 改 的 间隔 时 间 ， 单 
位 为 秒 。 当 我 们 与 Spring Cloud Config 配合 ， 
动态 刷新 Eureka 的 serviceURL 地 址 时 需要 关 
注 该 参数 
村 
0 | 


读 取 Eureka Server 信息 的 超时 时 间 ， 单 位 为 秒 |8 。 ”| 
连接 Eureka Server 的 超时 时 间 ， 单 位 为 秒 

eurekaServerTotalConnections 从 Eureka 客户 端 到 所 有 Eureka 服务 端的 连接 

eurekaServerTotalConnectionsPerHost 从 Eureka 客户 端 到 每 个 Eureka 服务 端 主机 的 | 

Em 

EN 

Ei 

Ei 

false 


Eureka 服务 端 连 接 的 空闲 关闭 时 间 ， 单 位 为 秒 

心跳 连接 池 的 初始 化 线程 数 

心跳 超时 重 试 延迟 时 间 的 最 大 乘 数值 

缓存 刷新 线程 池 的 初始 化 线程 数 

缓存 刷新 重 试 延迟 时 间 的 最 大 乘 数值 

使 用 DNS 来 获取 Eureka 服务 端的 serviceUrl | false 

是 否 要 将 自身 的 实例 信息 注册 到 Eureka 服务 端 
preferSameZoneEureka 是 否 偏好 使 用 处 于 相同 Zone 的 Eureka 服务 端 

获取 实例 时 是 否 过 滤 ， 仅 保留 UP 状态 的 实例 


fetchRegistry 是 否 从 Eureka 服务 端 获 取 注 册 信 息 


服务 实例 类 配置 
关于 服务 实例 类 的 配置 信息 ， 我 们 可 以 通过 查看 


org.Springframework.cloud.netflix.eureka.EurekaInstanceConfigBean ”的 源 
人 码 来 获取 详细 内 容 ， 这 些 配 置信 息 都 以 eureka.instance 为 前 级 ， 下 面 我 们 
针对 一 些 常 用 的 配置 信息 做 一 些 详细 的 说 明 。 

元 数据 

在 org.springframework.cloud.netflix.eureka.EurekaInstanceConfigBean 
的 配置 信息 中 ， 有 一 大 部 分 内 容 都 是 对 服务 实例 元 数据 的 配置 ， 那 么 什 
么 是 服务 实例 的 元 数据 呢 ? 它 是 Eureka 客 户 端 在 向 服务 注册 中 心 发 送 注 
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册 请 求 时 ， 用 来 描述 自身 服务 信息 的 对 象 ， 其 中 包含 了 一 些 标准 化 的 元 
数据 ， 比 如 服务 名 称 、 实 例 名 称 、 实 例 耻 、 实 例 端口 等 用 于 服务 治理 的 
; 以 及 一 些 用 于 负载 均衡 策略 或 是 其 他 特殊 用 途 的 自 定 义 元 数 

在 使 用 Spring Cloud Eureka 的 时 候 ， 所 有 的 配置 信息 都 通过 
org.Springframework.cloud.netflix.eureka.EurekaInstanceConfigBean 进 行 加 
载 ， 但 在 真正 进行 服务 注册 的 时 候 ， 还 是 会 包装 成 
com.netflix.appinfo.InstanceInfo 对 象 发 送 给 Eureka 服务 端 。 这 两 个 类 的 
定义 非常 相似 ， 我 们 可 以 直接 查看 com.netflix.appinfo.InstanceInfo 类 中 
的 详细 定义 来 了 解 原生 Eureka 对 元 数据 的 定义 。 其 中 ， 
Map<String, String> metadata=new ConcurrentHash Map<String,String> () 
是 自 定 义 的 元 数据 信息 ， 而 其 他 成 员 变 量 则 是 标准 化 的 元 数据 信息 。 
Spring Cloud 的 EurekaInstanceConfigBean 对 原生 元 数据 对 象 做 了 一 些 配 
置 优化 处 理 ， 在 后 续 的 介绍 中 ， 我 们 也 会 提 到 这 些 内 容 。 

我 们 可 以 通过 eureka.instance.<properties>=<value> 的 格式 对 标准 化 元 
数据 直接 进行 配置 ， 其 中 <properties> 就 是 EurekaInstanceConfigBean 对 象 
中 的 成 员 变 量 名 。 而 对 于 上 自 定义 元 数据 ， 可 以 通过 
eureka.instance.metadataMap.<key>=<value> 的 格式 来 进行 配置 ， 比 如 : 

eureka.instance.metadataMap.zone=shanghai 


接 下 来 ， 我 们 将 针对 一 些 常用 的 元 数据 配置 做 进一步 的 介绍 和 说 


实例 名 配置 
实例 名 ， 即 PnstanceInfo 中 的 instanceId 参 数 ， 它 是 区 分 同一 服务 中 不 
同 实例 的 唯一 标识 。 在 Netflixz Eureka 的 原生 实现 中 ， 实 例 名 采用 主机 名 
作为 默认 值 ， 这 样 的 设置 使 得 在 同一 主机 上 无 法 局 动 多 个 相同 的 服务 实 
例 。 所 以 ， 在 Spring Cloud Eureka 的 配置 中 ， 针 对 同一 主机 中 局 动 多 实 
例 的 情况 ， 对 实例 名 的 默认 命名 做 了 更 为 合理 的 扩展 ， 它 采用 了 如 下 默 
认 规 则 : 
${spring.cloud.client.hostname}:${spring.application.name}:${spring.app 
对 于 实例 名 的 命名 规则 ， 我 们 可 以 通过 eureka.instance.instanceId 参 数 
来 进行 配置 。 比 如 ， 在 本 地 进行 客户 端 负载 均衡 调试 时 ， 需 要 局 动 同一 
服务 的 多 个 实例 ， 如 果 我 们 直接 启动 同一 个 应 用 必然 会 产生 站 口 冲突 。 
虽然 可 以 在 命令 行 中 指定 不 同 的 server.port 来 启动 ， 但 是 这 样 还 是 略 显 
麻烦 。 实 际 上 ， 我 们 可 以 直接 通过 设置 server.port=0 或 者 使 用 随机 数 
server.port=${random.int[10000,19999]} 来 让 Tomcat 启 动 的 时 候 采 用 随机 
端口 。 但 是 这 个 时 候 我 们 会 发 现 注册 到 Eureka Server 的 实例 名 都 是 相同 
的 ， 这 会 使 得 只 有 一 个 服务 实例 能 够 正常 提供 服务 。 对 于 这 个 问题 ， 我 
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们 就 可 以 通过 设置 实例 名 规则 来 轻松 解决 : 
eureka.instance.instanceld=${spring.application.name}:${random.int}} 
通过 上 面 的 配置 ， 利 用 应 用 名 加 随机 数 的 方式 来 区 分 不 同 的 实例 ， 

人 
端点 配 
在 InstanceInfo 中 ， 我 们 可 以 看 到 一 些 URL 的 配置 信息 ， 比 如 

homePageUrl、statusPageUrl、healthCheckUrl， 它 们 分 别 代 表 了 应 用 主 

页 的 URL、 状 态 页 的 URL、 健 康 检查 的 URL。 其 中 ， 状 态 页 和 健康 检查 

的 URL 在 Spring Cloud Eureka 中 默认 使 用 了 spring-boot-actuator 模 块 提供 

的 /info 兽 点 和 /health 端 点 。 昌 然 我 们 在 之 前 的 示例 中 并 没有 对 这 些 端 点 

做 具体 的 设置 ， 但 是 实际 上 这 些 URL 地 址 的 配置 非常 重要 。 为 了 服务 的 

正常 运作 ， 我 们 必须 确保 Eureka 客户 端的 health 端点 在 发 送 元 数据 的 

时 候 ， 是 一 个 能 够 被 注册 中 心 访问 到 的 地 址 ， 铭 则 服务 注册 中 心 不 会 根 

据 应 用 的 健康 检查 来 更 改 状 态 〈 仅 当 开 局 了 healthcheck 功 能 时 ， 以 该 端 

点 信息 作为 健康 检查 标准 ) 。 而 /info ”端点 如 果 不 正确 的 话 ， 会 导致 在 

Eureka 面 板 中 单 击 服务 实例 时 ， 无 法 访问 到 服务 实例 提供 的 信息 接口 。 
大 多 数 情况 下 ， 我 们 并 不 需要 修改 这 几 个 URL 的 配置 ， 但 是 在 一 些 

特殊 情况 下 ， 比 如 ， 为 应 用 设置 了 context-path， 这 时 ， 所 有 spring-boot- 

actuator 模 块 的 监控 端点 都 会 增加 一 个 前 级。 所 以 ， 我 们 就 需要 做 类 似 

如 下 的 配置 ， 为 /info 和 /health 端点 也 加 上 类 似 的 前 级 信息 : 
management.context-path=/hello 
eureka.instance.statusPageUrlPath=${management.context-path }/info 
eureka.instance.healthCheckUrlPath=$ {management.context-path }/health 
男 外 ， 有 时 候 为 了 安全 考虑 ， 也 有 可 能 会 修改 /info 和 /health 端点 的 

台 路 径 。 这 个 时 候 ， 我 们 也 需要 做 一 些 特殊 的 配置 ， 比 如 像 下 面 这 
endpoints.info.path=/appInfo 
endpoints.health.path=/checkHealth 
eureka.instance.statusPageUrlPath=/${endpoints.info.path} 
eureka.instance.healthCheckUrlPath=/${endpoints.health.path} 

在 上 面 所 举 的 两 个 示例 中 ， 我 们 使 用 了 
eureka.instance.statusPageUrlPath 和 eureka.instance.healthCheckUrlPath 参 
数 ， 这 两 个 配置 值 有 一 个 共同 特点 ， 它 们 都 使 用 相对 路 径 来 进行 配置 。 
由 于 Eureka 的 服务 注册 中 心 默认 会 以 HTTP 的 方式 来 访问 和 骏 露 这 些 疹 
扩 ， 因 此 当 客 户 端 应 用 以 HTTPS 的 方式 来 其 露 服务 和 监控 并 点 时 ， 相 对 
路 径 的 配置 方式 束 无 法 满足 需求 了 。 所 以 ，Spring Cloud Eureka 还 提供 
了 绝对 路 径 的 配置 参数 ， 具 体 示 例如 下 所 示 : 








eureka.instance.statusPageUrl=https://${eureka.instance.hostname}/info 

eureka.instance.healthCheckUrl=https://${eureka.instance.hostname }/heal 

eureka.instance.homePageUrl=https://${eureka.instance.hostname}/ 

健康 检测 

默认 情况 下 ，Eureka 中 各 个 服务 实例 的 健康 检测 并 不 是 通过 spring- 
boot-actuator 模 块 的 /health ”端点 来 实现 的 ， 而 是 依靠 客户 端 心跳 的 方式 
来 保持 服务 实例 的 存活 。 在 Eureka 的 服务 续 约 与 剔除 机 制 下 ， 客 户 端的 
健康 状态 从 注册 到 注册 中 心 开 始 都 会 处 于 UP 状态 ， 除 非 心跳 终止 一 段 
时 间 之 后 ， 服 务 注册 中 心 将 其 剔除 。 默 认 的 心跳 实现 方式 可 以 有 效 检查 
客户 端 进程 是 否 正 癌 运 作 ， 但 却 无 法 保证 客户 站 应 用 能 够 正 癌 提 供 服 
务 。 由 于 大 多 数 微服 务 应 用 都 会 有 一 些 其 他 的 外 部 资源 依赖 ， 比 如 数据 
库 、 缓 存 、 消 息 代 理 等 ， 如 果 我 们 的 应 用 与 这 些 外 部 资源 无 法 联通 的 时 
候 ， 实 际 上 已 经 不 能 提供 正常 的 对 外 服务 了 ， 但 是 因为 客户 端 心跳 依然 
在 运行 ， 所 以 它 还 是 会 被 服务 消费 者 调用 ， 而 这 样 的 调用 实际 上 并 不 能 
获得 预期 的 结果 。 

在 Spring Cloud Eureka 中 ， 我 们 可 以 通过 简单 的 配置 ， 把 Eureka 客 户 
端的 健康 检测 交 给 spring-boot-actuator 模 块 的 /health 端 点 ， 以 实现 更 加 全 
面 的 健康 状态 维护 。 详 细 的 配置 步骤 如 下 上 所 示 : 

e 在 pom.xml 中 引入 spring-boot-starter-actuator 模 块 的 依赖 。 

e 在 application.properties 中 增加 参数 配置 
eureka.client.healthcheck.enabled=true。 

e 如 果 客 户 端 的 /health 病 点 路 径 做 了 一 些 特殊 处 理 ， 请 参考 前 文 介绍 
痢 必 配置 时 的 方法 进行 配置 ， 让 服务 注册 中 心 可 以 正确 访问 到 健康 检测 
好 后 。 

其 他 配置 

除了 上 面 介绍 的 配置 参数 外 ， 下 面 整理 了 一 些 
org.Springframework.cloud.netflix.eureka.EurekaInstanceConfigBean 中 定 
义 的 配置 参数 以 及 对 应 的 说 明和 默认 值 ， 这 些 参数 均 以 eureka.instance 为 
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参数 名 


是 否 优先 使 用 IP 地 址 作为 主机 名 的 标识 
Bureka 客户 端 向 服务 端 发 送 心跳 的 时 间 问 页 ， 单位 为 种 | 30 


alse | 
leaseExpirationDurationInSeconds | Eureka 服务 端 在 收 到 最 后 一 次 心跳 之 后 等 待 的 时 间 上 限 ， ”| 
单位 为 秒 。 超 过 该 时 间 之 后 服务 端 会 将 该 服务 实例 从 服务 
清单 中 剔除 ， 从 而 禁止 服务 调用 请 求 被 发 送 到 该 实例 上 
人 策 一 
是 否 启用 非 安全 的 通信 端口 号 true 
古语 用 全 双人 和 
appname 服务 名 ,默认 取 spring .application .name 的 配置 值 ， 
如 果 没 有 则 为 unknown | 
主机 名 ， 不 配置 的 时 候 将 根据 操作 系统 的 主机 名 来 获取 | | 
在 上 面 的 这 些 配置 中 ， 除 了 前 三 个 配置 参数 在 需要 的 时 候 可 以 做 一 
些 调整 ， 其 他 的 参数 配置 大 多 数 情况 下 不 需要 进行 配置 ， 使 用 默认 值 即 
可 。 





路 平 侣 支持 


在 “Eureka 详 解 ” 一 节 中 ， 我 们 对 Spring Cloud Eureka 的 源码 做 了 较为 
详细 的 分 析 ， 在 分 析 过 程 中 相信 大 家 已 经 发 现 ，Eureka 的 通信 机 制 使 用 
了 HTTP 的 REST 接 口 实现 ， 这 也 是 Eureka 同 其 他 服务 注册 工具 的 一 个 关 
键 不 同 点 。 由 于 HTTP 的 平台 无 关 性 ， 虽 然 Eureka Server 通 过 Java 实 现 ， 
但 是 在 其 下 的 微服 务 应 用 并 不 限于 使 用 Java 来 进行 开发 。 

跨 平 台 本 喘 就 是 微服 务 架构 的 九 大 特性 之 一 ， 只 有 实现 了 对 技术 平 
台 的 透明 ， 才 能 更 好 地 发 挥 不 同 语言 对 不 同业 务 处 理 能 力 的 优势 ， 从 而 
打造 更 为 强大 的 大 型 系统 。 

目前 除了 Eureka 的 Java 客户 端 之 外 ， 还 有 很 多 其 他 语言 平台 对 其 的 
支持 ， 比 如 eureka-js-client、python-eureka 等 。 若 我 们 有 志 于 自己 为 一 门 
语言 来 开发 客户 端 程序 ， 也 并 非特 别 复杂 ， 只 需要 根据 上 面 提 到 的 那些 
用 户 服 务 协调 的 通信 请 求实 现 束 能 实现 服务 的 注册 与 发 现 ， 需 要 了 解 更 
多 关于 Eureka 的 REST API 内 容 可 以 查看 Eureka 官 方 WiKi 中 的 Eureka- 
REST-operations— XChttps://github.com/Netflix/eureka/wiki/Eureka-REST- 
Operations 。 

通信 协议 

默认 情况 下 ，Eureka 使 用 Jersey 和 XStream 配 合 JSON 作 为 Server 与 
Client 之 间 的 通信 协议 。 你 也 可 以 选择 实现 自己 的 协议 来 代替 。 

eJersey 是 JAX-RS 的 参考 实现 ， 它 包含 三 个 主要 部 分 。 

四 核心 服务 器 (Core Server) : 通过 提供 JSR 311 中 标准 化 的 注释 和 
API 标准 化 ， 你 可 以 用 直观 的 方式 开发 RESTful Web 服务 。 

加 核心 窗户 端 〈Core Client) :Jersey 客户 端 API 帮助 你 与 REST 服务 
轻松 通信 。 

加 集成 〈JIntegration ) :Jersey 还 提供 可 以 轻松 集成 Spring、Gmuice、 
Apache Abdera 的 库 。 

eXStream 是 用 来 将 对 象 序列 化 成 XML (JSON) 或 反 序列 化 为 对 象 
的 一 个 Java 类 库 。XStream 在 运行 时 使 用 Java 反 射 机 制 对 要 进行 序列 化 的 
对 象 树 的 结构 进行 探索 ， 并 不 需要 对 对 象 做 出 修改 。XStream 可 以 序列 
化 内 部 字段 ， 包 括 private 和 final 字 段 ， 并 且 文 持 非 公开 类 以 及 内 部 类 。 
默认 情况 下 ，XStream 不 需要 配置 映射 关系 ， 对 象 和 字段 将 映射 为 同名 
XML 元 素 。 但 是 当 对 象 和 字段 名 与 XML 中 的 元 素 名 不 同时 ，XStream 文 
持 指 定 别 名 。XStream 文 持 以 方法 调用 的 方式 ， 或 是 Java 标注 的 方式 指 
定 别 名 。XStream ”在 进行 数据 类 型 转换 时 ， 使 用 系统 默认 的 类 型 转换 
器 。 同 时 ， 也 支持 用 户 自 定义 的 类 型 转换 器 。 























JAX-RS 是 将 在 Java EE 6 中 引入 的 一 种 新 技术 。JAX-RS 即 Java API 
for RESTful Web Services， 是 一 个 Java 编程 语言 的 应 用 程序 接口 ， 文 持 
按照 表述 性 状态 转移 REST) 架构 风格 创建 Web 服 务 。JAX-RS 使 用 了 
人 5 引入 的 Java 标 注 来 简化 Web 服务 的 客户 端 和 服务 端的 开发 和 部 

5 舌 : 

e@Path， 标 注资 源 类 或 者 方法 的 相对 路 径 。 

e@GET、@PUT、@POST、Q@DELETE， 标 注 方 法 是 HTTP 请 求 的 
类 型 。 

e(@Produces， 标 注 返 回 的 MIME 媒 体 类 型 。 

e@Consumes， 标 注 可 接受 请 求 的 MIME 媒 体 类 型 。 

e(WPathParam、 (QueryParam、 (OHeaderParam、 (CookieParam.、 
(DMatrixParam.、 

@FormParam， 标 注 方法 的 参数 来 自 HTTP 请 求 的 不 同位 置 ， 例 如 ， 
(OPathParam 

来 自 URE 的 路 径 ，@QueryParam 来 自 URL 的 查询 参数 ， 
@HeaderParam 来 自 

HTTP 请 求 的 头 信 息 ，@CookieParam 来 自 HTTP 请 求 的 Cookie。 

之 前 在 分 析 Eureka Server 端 源码 的 时 候 ， 碍 看 请 求 处 理 时 可 以 看 到 很 
多 上 面 这 些 注解 的 定义 。 





第 4 音 安 - 户 关 人 负载 均衡 ，，Sprin 
Cloud Ribbon 


Spring Cloud Ribbon 是 一 个 基于 HITP 和 TCP 的 客户 端 负 载 均 衡 工 
具 ， 它 基于 Netflix Ribbon 实 现 。 通 过 Spring Cloud 的 封装 ， 可 以 让 我 们 
轻松 地 将 面向 服务 的 REST 模 板 请 求 自动 转换 成 客户 端 负载 均衡 的 服务 
调用 。Spring Cloud Ribbon 虽 然 只 是 一 个 工具 类 框架 ， 它 不 像 服 务 注 册 
中 心 、 配 置 中 心 、API 网 关 那 样 需要 独立 部 普 ， 但 是 它 几 乎 存在 于 每 一 
个 Spring Cloud 构 建 的 微服 务 和 基础 设施 中 。 因 为 微服 务 间 的 调用 ，API 
网 关 的 请 求 转发 等 内 容 ， 实 际 上 都 是 通过 Ribbon 来 实现 的 ， 包 括 后 续 我 
们 将 要 介绍 的 Feign， 它 也 是 基于 Ribbon 实 现 的 工具 。 所 以 ， 对 Spring 
Ribbon 的 理解 和 使 用 ， 对 于 我 们 使 用 Spring Cloud 来 构建 微服 务 非 
党 重要 。 

在 这 一 章 中 ， 我 们 将 具体 介绍 如 何 使 用 Ribbon 来 实现 客户 问 的 负载 
均衡 ， 并 且 通 过 源码 分 析 来 了 解 Ribbon 实 现 客户 端 负载 均衡 的 基本 原 
理 。 








宫 » 端 负 载 坟 衡 


负载 均衡 在 系统 架构 中 是 一 个 非常 重要 ， 并 且 是 不 得 不 去 实施 的 内 
容 。 因 为 负载 均衡 是 对 系统 的 高 可 用 、 网 络 压 力 的 缓解 和 处 理 能 力 扩容 
的 重要 手段 之 一 。 我 们 通 第 所 说 的 负载 均衡 部 指 的 是 服务 端 负载 均衡 ， 
其 中 分 为 硬件 负载 均衡 和 软件 负载 均衡 。 硬 件 负载 均衡 主要 通过 在 服务 
器 节点 之 间 安 装 专门 用 于 负载 均衡 的 设备 ， 比 如 F5 等 ， 而 软件 负载 均衡 
则 是 通过 在 服务 器 上 安装 一 些 具 有 均衡 负载 功能 或 模块 的 软件 来 完成 请 
求 分 发 工作 ， 比 如 Nginx ” 等。 不论 采用 人 硬件 负载 均衡 还 是 软件 负载 均 
衡 ， 只 要 是 服务 病 负 载 均衡 部 能 以 类 似 下 图 的 架构 方式 构建 起 来 : 




















硬件 负载 均衡 的 设备 或 是 软件 负载 均衡 的 软件 模块 都 会 维护 一 个 下 
挂 可 用 的 服务 端 清 单 ， 通 过 心跳 检测 来 剔除 故障 的 服务 端 节 点 以 保证 清 
单 中 都 是 可 以 正常 访问 的 服务 端 节点 。 当 客户 端 发 送 请 求 到 负载 均衡 设 
备 的 时 候 ， 该 设备 按 某 种 算法 (比如 线性 轮 询 、 按 权重 负载 、 按 流量 负 
谢 竺 从 维护 的 可 用 服务 端 清单 中 取出 一 全 服务 端的 地 址 ， 然 后 进行 苇 





而 客户 端 负载 均衡 和 服务 端 负 载 均衡 最 大 的 不 同 点 在 于 上 面 所 提 到 
的 服务 清单 所 存储 的 位 置 。 在 客户 端 负 载 均衡 中 ， 所 有 客户 端 节 点 都 维 
护 着 目 己 要 访问 的 服务 端 清 单 ， 而 这 些 服务 端的 清单 来 目 于 服务 注册 中 
心 ， 比 如 上 一 章 我 们 介绍 的 Eureka 服 务 端 。 同 服务 端 负载 均衡 的 架构 类 
似 ， 在 客户 端 负 载 均 衡 中 也 需要 心跳 去 维护 服务 端 清单 的 健康 性 ， 只 是 
这 个 步骤 需要 与 服务 注册 中 心 配 合 完成 。 在 Spring Cloud 实现 的 服务 治 
理 框架 中 ， 默 认 会 创建 针对 各 个 服务 治理 框架 的 Ribbon 自动 化 整合 配 
置 ， 比 如 Eureka 中 的 


org.Springframework.cloud.netflix.ribbon.eureka.RibbonEurekaAutoConfigur 








org.Springframework.cloud.consul.discovery.RibbonConsulAutoConfiguratiol 
在 实际 使 用 的 时 候 ， 我 们 可 以 通过 查看 这 两 个 类 的 实现 ， 以 找到 它们 的 
配置 详情 来 帮助 我 们 更 好 地 使 用 它 。 

通过 Spring Cloud Ribbon 的 封 浪 ， 我 们 在 微服 务 架构 中 使 用 客户 端 负 
载 均 衡 调 用 非常 简单 ， 只 需要 如 下 两 步 : 

e 服 务 提 供 者 只 需要 局 动 多 个 服务 实例 并 注册 到 一 个 注册 中 心 或 是 多 
个 相关 联 的 服务 注册 中 心 。 

e 服 务 消费 者 直接 通过 调用 被 @LoadBalanced 注 解 修饰 过 的 
RestTemplate 来 实现 面 同 服务 的 接口 调用 。 

这 样 ， 我 们 就 可 以 将 服务 提供 者 的 高 可 用 以 及 服务 消费 者 的 负载 均 
衡 调 用 一 起 实现 了 。 





RestTemplate 详 解 


在 上 一 章 中 ， 我 们 已 经 通过 引入 Ribbon 实 现 了 服务 消费 者 的 客户 端 
负载 均衡 功能 ， 读 者 可 以 通过 得 看 第 3 章 中 的 “服务 发 现 与 消费 ”一 节 来 
获取 实验 示例 。 其 中 ， 我 们 使 用 了 一 个 非常 有 用 的 对 象 RestTemplate。 
该 对 象 会 使 用 Ribbon 的 目 动 化 配置 ， 同 时 通过 配置 @LoadBalanced 还 能 
够 开局 客户 端 负载 均衡 。 之 前 我 们 演示 了 通过 RestTemplate 实 现 了 最 简 
单 的 服务 访问 ， 下 面 我 们 将 详细 介绍 RestTemplate 针对 几 种 不 同 请 求 类 
型 和 参数 类 型 的 服务 调用 实现 。 


GET 请 求 


在 RestTemplate 中 ， 对 GET 请 求 可 以 通过 如 下 两 个 方法 进行 调用 实 
现 。 

第 一 种 : getForEntity 函 数 。 该 方法 返回 的 是 ResponseEntity， 访 对象 
是 Spring 对 HTTP 请 求 啊 应 的 封装 ， 其 中 主要 存储 了 HTTP 的 几 个 重要 元 
素 ， 比 如 HITP 请 求 状态 码 的 枚 举 对 象 httpStatus〈 也 就 是 我 们 常 说 的 
404、500 这 些 错 误 码 ) 、 在 它 的 父 类 HttpEntity 中 还 存储 着 HTTP 请 求 的 
头 信 息 对 象 HttpHeaders 以 及 泛 型 类 型 的 请 求 体 对 象 。 比 如 下 面 的 例子 ， 
就 是 访问 USER-SERVER 服 务 的 /aser 请 求 ， 同 时 最 后 一 个 参数 didi 会 蔡 
换 url 中 的 {1} 占 位 符 ， 而 返回 的 ResponseEntity 对 象 中 的 body 内 容 类 型 会 
根据 第 二 个 参数 转换 为 String 类 型 。 

RestTemplate restTemplate=new RestTemplate () ; 

ResponseEntity<String> 
responseEntity=restTemplate.getForEntity ("http:/USER-SERVICE/user? 
name={1}",String.class,"didi" ) ; 

String body=responseEntity.getBody () ; 

若 我 们 希望 返回 的 body 是 一 个 User 对 象 类 型 ， 也 可 以 这 样 实现 : 

RestTemplate restTemplate=new RestTemplate () ; 

ResponseEntity<User> 
responseEntity=restTemplate.getForEntity ("http:/USER-SERVICE/user? 
name={1}",User.class,"didi") ， 

User body=responseEntity.getBody (); 

上 面 的 例子 是 比较 常用 的 方法 ，getForEntity 函 数 实际 上 提供 了 以 下 
三 种 不 同 的 重 载 实现 。 

















egetForEntity (String url,Class responseType,Object...urlVariables) : 
该 方法 提供 了 三 个 参数 ， 其 中 url 为 请 求 的 地 址 ，responseType 为 请 求 
响应 体 body 的 包装 类 型 ，urlVariables 为 url 中 的 参数 绑 定 。GET 请 求 的 参 
数 绑 定 通常 使 用 url 中 拼接 的 方式 ， 比 如 http://USER-SERVICE/user? 
name=didi， 我 们 可 以 像 这 样 自己 将 参数 拼接 到 unl 中， 但 更 好 的 方法 是 
在 url 中 使 用 占 位 符 并 配合 urlVariables 参数 实现 GET 请 求 的 参数 绑 定 ， 
比如 ur 定义 为 http://USER-SERVICE/user? name={1}， 然 后 可 以 这 样 来 
调用 : getForEntity ("http://USER-SERVICE/user? name= 
{1}",String.class,"didi") ， 其 中 第 三 个 参数 didi 会 将 换 url 中 的 {1} 占 位 
符 。 这 里 需要 注意 的 是 ， 由 于 urlVariables 参数 是 一 个 数组 ， 所 以 它 的 顺 
序 会 对 应 ul 中 占 位 符 定义 的 数字 顺序 。 

egetForEntity (String url,Class responseType,Map urlVariables) : 该 
方法 提供 的 参数 中 ， 只 有 urlVariables 的 参数 类 型 与 上 面 的 方法 不 同 。 
这 里 使 用 了 Map 类 型 ， 所 以 使 用 该 方法 进行 参数 绑 定时 需要 在 占 位 符 中 
指定 Map ”中 参数 的 key 值 ， 比 如 ul 定义 为 http:WUSER-SERVICEmser? 
name={name}， 在 Map 类 型 的 urlVariables 中 ， 我 们 就 需要 put 一 个 key 为 
name 的 参数 来 绑 定 url 中 {name} 占 位 符 的 值 ， 比 如 : 

RestTemplate restTemplate=new RestTemplate () ; 

Map<String,String> params=new Hash Map<> 〈) ; 

params.put ("name","dada") ; 

ResponseEntity<String> 
responseEntity=restTemplate.getForEntity ("http:/USER-SERVICE/user? 
name={name}",String.class,params) ; 

egetForEntity (URI url,Class responseType) : 该 方法 使 用 URI 对 象 来 
蔡 代 之 前 的 un 和 urlVariables 参 数 来 指定 访问 地 址 和 参数 绑 定 。URI 是 
JDK java.net 包 下 的 一 个 类 ， 它 表示 一 个 统一 资源 标识 符 (Uniform 
Resource Identifier) 引用 。 比 如 下 面 的 例子 : 

RestTemplate restTemplate=new RestTemplate () ; 

UriComponents 
uriComponents=UriComponentsBuilder.fromUriString ( 

"http://USER-SERVICE/user? name={name}") 

.build () 

.expand ("dodo") 

.encode () ; 

URI uri=uriComponents.toUri (); 

ResponseEntity<String> 
responseEntity=restTemplate.getForEntity (uri,String.class) .getBody (); 








更 多 关于 如 何 定义 一 个 URI 的 方法 可 以 参见 JDK 文 档 ， 这 里 不 做 详细 
说 明 。 

第 二 种 : getForObject 函 数 。 该 方法 可 以 理解 为 对 getForEntity 的 进 一 
步 封 装 ， 它 通过 HttpMessageConverterExtractor 对 HTTP 的 请 求 响应 体 
body 内 容 进行 对 象 转换 ， 实 现 请求 直 接 返 回 包装 好 的 对 象 内 容 。 比 如 : 

RestTemplate restTemplate=new RestTemplate () ; 

String result=restTemplate.getForObject (uri,String.class) ; 

当 body 是 一 个 User 对 象 时 ， 可 以 直接 这 样 实现 : 

RestTemplate restTemplate=new RestTemplate () ; 

User result=restTemplate.getForObject (uri,User.class) ; 

当 不 需要 关注 请 求 啊 应 除 body 外 的 其 他 内 容 时 ， 该 函数 就 非常 好 
用 ， 可 以 少 一 个 从 Response 中 获取 body 的 步骤 。 它 与 getForEntity 函 数 类 
似 ， 也 提供 了 三 种 不 同 的 重 载 实现 。 

egetForObject (String url,Class responseType,Object...urlVariables) : 
与 getForEntity 的 方法 类 似 ，url 参 数 指定 访问 的 地 址 ，responseType 参 数 
定义 该 方法 的 返回 类 型 ，urlVariables 参 数 为 url 中 占 位 符 对 应 的 参数 。 

egetForObject (String url,Class responseType,Map urlVariables) : 在 
该 函数 中 ， 使 用 Map 类 型 的 urlVariables 替 代 上 面 数 组 形式 的 
urlVariables， 因 此 使 用 时 在 url 中 需要 将 占 位 符 的 名 称 与 Map 类 型 中 的 
key 一 一 对 应 设置 。 

egetForObject (URI url,Class responseType) : 该 方法 使 用 URI 对 象 
来 蔡 代 之 前 的 url 和 urlVariables 参 数 使 用 。 


POST 请 求 


在 RestTemplate 中 ， 对 POST 请 求 时 可 以 通过 如 下 三 个 方法 进行 调用 
实现 。 

第 一 种 : postForEntity 函 数 。 该 方法 同 GET 请 求 中 的 getForEntity 关 
似 ， 会 在 调用 后 返回 ResponseEntity<T> 对 象 ， 其 中 IT 为 请 求 响 应 的 body 
类 型 。 比 如 下 面 这 个 例子 ， 使 用 postForEntity 提 交 POST 请 求 到 USER- 
SERVICE 服 务 的 /user 接 口 ， 提 交 的 body 内 容 为 user 对 象 ， 请 求 啊 应 返回 
的 body 类 型 为 String。 

RestTemplate restTemplate=new RestTemplate () ; 

User user=new User ("didi",30) ; 

ResponseEntity<String> responseEntity= 

restTemplate.postForEntity ("http://USER- 
SERVICE/user",user,String.class) ; 


String body=responseEntity.getBody 〈) ; 

postForEntity 函 数 也 实现 了 三 种 不 同 的 重 载 方法 。 

epostForEntity (String url,Object request,Class 
responseType,Object...uriVariables) 

epostForEntity (String url,Object request,Class responseType,Map 
uriVariables) 

epostForEntity (URI url,Object request,Class responseType) 

这 些 函 数 中 的 参数 用 法 大 部 分 与 getForEntity 一 致 ， 比 如 ， 第 一 个 重 
载 函 数 和 第 二 个 重 载 函数 中 的 uriVariables 参数 都 用 来 对 url 中 的 参数 进 
行 绑 定 使 用 :responseType 人 参数 是 对 请 求 啊 应 的 body 内 容 的 类 型 定义 。 
这 里 需要 注意 的 是 新 增加 的 request 参 数 ， 该 参数 可 以 是 一 个 普通 对 象 ， 
也 可 以 是 一 个 HttpEntity 对 象 。 如 果 是 一 个 普通 对 象 ， 而 非 HttpEntity 对 
的 时 候 ， RestTemplate 会 会 将 请 求 对 象 转换 为 一 个 HttpEntity 对 象 来 处 

里 ， 其 中 Object 就 是 request 的 类 型 ，request 内 容 会 被 视 作 完整 的 body 来 
让 而 如 果 request 是 一 个 HttpEntity 对 象 ， 那 么 就 会 被 当 作 一 个 完成 的 
http 请 求 对 象 来 处 理 ， 这 个 request 中 不 仪 包含 了 body 的 内 容 ， 也 包含 
了 header 的 内 容 。 

第 二 种 : postForObject 函数 。 该 方法 也 跟 ”getForObject 的 类 型 类 
似 ， 它 的 作用 是 简化 postForEntity 的 后 续 处 理 。 通 过 直接 将 请 求 啊 应 的 
body 内 容 包装 成 对 象 来 返回 使 用 ， 比 如 下 面 的 例子 : 

RestTemplate restTemplate=new RestTemplate () ; 

User user=new User 〈"didi",20) ; 

String postResult=restTemplate.postForObject ("http://USER- 
SERVICE/user",user,String.class) ; 

postForObject 函 数 也 实现 了 三 种 不 同 的 重 载 方 法 : 

epostForObject (String url,Object request,Class 
responseType,Object...uriVariables) 

epostForObject (String url,Object request,Class responseType,Map 
uriVariables) 

epostForObject (URI url,Object request,Class responseType) 

这 三 个 函数 除了 返回 的 对 象 类 型 不 同 ， 函 数 的 传 入 参数 均 与 
postForEntity 一 致 ， 因 此 可 参考 之 前 postForEntity 的 说 明 。 

第 三 种 : postForLocation 函 数 。 该 方法 实现 了 以 POST 请 求 提 交 资 
源 ， 并 返回 新 资源 的 URI， 比 如 下 面 的 例子 : 

User user=new User ("didi",40) ; 

URI responseURI=restTemplate.postForLocation ("http://USER- 
SERVICE/user",user) ; 


postForLocation 浮 数 也 实现 了 三 种 不 同 的 重 载 方法 : 

epostForLocation (String url,Object request,Object...urlVariables) 

epostForLocation (String url,Object request,Map urlVariables) 

epostForLocation (URI url,Object request) 

由 于 postForLocation 疯 数 会 返回 新 资源 的 URI， 该 URI 就 相当 于 指定 
了 返回 类 型 ， 所 以 此 方法 实现 的 POST 请 求 不 需要 像 postForEntity 和 
postForObject 那 样 指定 responseType。 其 他 的 参数 用 法 相同 。 


PUT 请求 


在 RestTemplate 中 ， 对 PUT 请 求 可 以 通过 put 方 法 进行 调用 实现 ， 比 
如 : 

RestTemplate restTemplate=new RestTemplate () ; 

Long id=10001L; 

User user=new User ("didi",40) ; 

restTemplate.put ("http://USER-SERVICE/user/{1}",user,id) ; 

put 函 数 也 实现 了 三 种 不 同 的 重 载 方法 : 

eput (String url,Object request,Object...urlVariables) 

eput (String url,Object request, Map urlVariables) 

eput (URI url,Object request) 

put 函 数 为 void 类 型 ， 所 以 没有 返回 内 容 ， 也 就 没有 其 他 函数 定义 的 
responseType 人 参数 ， 除 此 之 外 的 其 他 传 入 参数 定义 与 用 法 与 
postForObject 基 本 一 致 。 


DELETE 请 求 


在 RestTemplate 中 ， 对 DELETE 请 求 可 以 通过 delete 方 法 进行 调用 实 
现 ? 比 如 3 

RestTemplate restTemplate=new RestTemplate () ; 

Long id=10001L; 

restTemplate.delete ("http:/USER-SERVICE/user/{1}",id) ; 

delete 隙 数 也 实现 了 三 种 不 同 的 重 载 方法 : 

edelete (String url,Object...urlVariables) 

edelete (String url,Map urlVariables) 

edelete (URI url) 

由 于 我 们 在 进行 REST 请 求 时 ， 通 常 都 将 DELETE 请 求 的 唯一 标识 拼 
接 在 unl 中 ， 所 以 DELETE 请 求 也 不 需要 request 的 body 信 息 ， 就 如 上 面 的 





三 个 函数 实现 一 样 ， 非 常 简单 。url 指 定 DELETE 请 求 的 位 置 ， 
urlVariables 绑 定 url 中 的 参数 即 可 。 


源码 分 析 


相信 很 多 熟悉 ” Spring ”的 读者 看 到 这 里 一 定 会 产生 这 样 的 疑问 : 
RestTemplate 不 是 Spring 自 己 束 提供 的 吗 ? 跟 Ribbon 的 客户 问 负 载 均衡 
又 有 什么 关系 呢 ? 在 本 市 中 ， 我 们 将 透 过 现象 看 本 质 ， 探 索 一 下 Ribbon 
是 如 何 通 过 RestTemplate 实 现 客 户 端 负载 均衡 的 。 

首先 ， 回 顾 一 下 之 前 的 消费 者 示例 : 我 们 是 如 何 实现 客户 端 负 载 均 
衡 的 ? 仔细 观察 一 下 之 前 的 实现 代码 ， 可 以 发 现在 消费 者 的 例子 中 ， 可 
能 束 @LoadBalanced 这 个 注解 是 之 前 没有 接触 过 的 ， 并 且 从 命名 上 来 看 
也 与 负载 均衡 相关 。 我 们 不 妨 以 此 为 线索 来 看 看 Spring Cloud Ribbon 的 
源码 实现 。 

从 @LoadBalanced 注解 源码 的 注释 中 可 以 知道 ， 该 注解 用 来 给 
RestTemplate 做 标记 ， 以 使 用 负载 均衡 的 客户 端 (LoadBalancerClient) 
来 配置 它 。 

通过 搜索 LoadBalancerClient 可 以 有 发现 ， 这 是 Spring Cloud 中 定义 的 一 
个 接口 : 

public interface LoadBalancerClient { 

ServiceInstance choose (String serviceld) ; 

<T> T execute (String serviceId,LoadBalancerRequest<T> request) 
throws IOException; 

URI reconstructURI (ServiceInstance instance,URI original) ; 

} 

从 该 接口 中 ， 我 们 可 以 通过 定义 的 抽象 方法 来 了 解 客 户 端 负载 均衡 
恬 中 应 具备 的 几 种 能 

eServicelInstance ”choose (String ”serviceId) : 根据 传 入 的 服务 名 
serviceld， 从 负载 均衡 器 中 挑选 一 个 对 应 服务 的 实例 。 

eT execute (String serviceld,LoadBalancerRequest request) throws 
IOException: 使 用 从 负载 均衡 器 中 挑选 出 的 服务 实例 来 执行 请 求 内 容 。 

eURI reconstructURI 〈ServiceInstance instance,URI original ) : 为 系 
统 构建 一 个 合适 的 host:port 形 式 的 URI。 在 分 布 式 系统 中 ， 我 们 使 用 逻 
辑 上 的 服务 名 称 作 为 host 来 构建 URI( 蔡 代 服 务实 例 的 host:port 形 式 ) 进 
行 请 求 ， 比 如 http://myservice/path/to/service。 在 该 操作 的 定义 中 ， 前 者 
ServiceInstance 对 象 是 带 有 host 和 port 的 具体 服务 实例 ， 而 后 者 URI 对 象 
则 是 使 用 逻辑 服务 名 定义 为 host 的 URI， 而 返回 的 URI 内 容 则 是 通过 
ServiceInstance 的 服务 实例 详情 拼接 出 的 具体 host:post 形 式 的 请 求 地 址 。 

顺 着 LoadBalancerClient 接口 的 所 属 包 








org.springframework.cloud.client.loadbalancer， 我 们 对 其 内 容 进 行 整理 ， 
可 以 得 出 如 下 图 所 示 的 关系 。 
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从 类 的 命名 上 可 初步 判断 LoadBalancerAutoConfiguration 为 实现 客 
户 端 负载 均衡 器 的 自动 化 配置 类 。 通 过 查看 源码 ， 我 们 可 以 验证 这 一 点 
假设 : 

@Configuration 

@ConditionalOnClass (RestTemplate.class) 

(@ConditionalOnBean (LoadBalancerClient.class) 

public class LoadBalancerAutoConfiguration { 

(LoadBalanced 

@Autowired (required=false) 

private List<RestTemplate> restTemplates=Collections.emptyList (); 

Bean 

public SmartInitializingSingleton loadBalancedRestTemplateInitializer ( 

final List<RestTemplateCustomizer> customizers ) { 

return new SmartInitializingSingleton () { 

(DOverride 

public void afterSingletonsInstantiated () { 

for (RestTemplate restTemplate : LoadBalancerAutoConfiguration. 

this.restTemplates) { 

for (RestTemplateCustomizer customizer : customizers) { 

customizer.customize (restTemplate) ; 


} 
|] 
} 
}; 


} 
DBean 


Q@ConditionalOnMissingBean 

public RestTemplateCustomizer restTemplateCustomizer ( 

final LoadBalancerInterceptor loadBalancerInterceptor) { 

return new RestTemplateCustomizer () { 

(DOverride 

public void customize (RestTemplate restTemplate) { 

List<ClientHttpRequestInterceptor> list=new ArrayList<> ( 

restTemplate.getInterceptors () ) ; 

list.add (loadBalancerInterceptor) ; 

restTemplate.setInterceptors (list) ; 

} 

y 

} 

Bean 

public LoadBalancerInterceptor ribbonInterceptor ( 

LoadBalancerClient loadBalancerClient) { 

return new LoadBalancerInterceptor (loadBalancerClient) ; 

} 

} 

从 LoadBalancerAutoConfiguration 类 头 上 的 注解 可 以 知道 ，Ribbon 实 
现 的 负载 均衡 自动 化 配置 需要 满足 下 面 两 个 条 件 。 

eOConditionalOnClass (RestTemplate.class ) :RestTemplate 类 必须 存 
在 于 当前 工程 的 环境 中 。 

eOConditionalOnBean (LoadBalancerClient.class) : 在 Spring 的 Bean 
工程 中 必须 有 LoadBalancerClient 的 实现 Bean。 

在 该 自动 化 配置 类 中 ， 主 要 做 了 下 面 三 件 事 : 

e 创 建 了 一 个 LoadBalancerInterceptor 的 Bean， 用 于 实现 对 客户 端 发 
起 请 求 时 进行 拦截 ， 以 实现 客户 端 负 载 均衡 。 

e 创 建 了 一 个 RestTemplateCustomizer 的 Bean， 用 于 给 RestTemplate 增 
加 LoadBalancerInterceptor 拦 截 器 。 

e 维 护 了 一 个 被 @LoadBalanced 注 解 修饰 的 RestTemplate 对 象 列表 ， 
并 在 这 里 进行 初始 化 ， 通 过 调用 RestTemplateCustomizer 的 实例 来 给 需 
要 客户 端 负载 均衡 的 RestTemplate 增 加 LoadBalancerInterceptor 拦 截 器 。 

接 下 来 ， 我 们 看 看 LoadBalancerInterceptor 拦截 器 是 如 何 将 一 个 普通 
的 RestTemplate 变 成 客户 端 负载 均衡 的 : 

















public class LoadBalancerInterceptor implements ClientHttpRequestInterceptor { 
private LoadBalancerClient loadBalancer; 


public LoadBalancerInterceptor (LoadBalancerClient loadBalancer) { 
this.loadBalancer = loadBalancer; 


QOverride 
public ClientHttpResponse intercept (final HttpRequest request, final byte[] body, 
final ClientHttpRequestExecution execution) throws IOException { 
final URI originalUri = request .getURI (); 
String serviceName = originalUri.getHost ();} 
return this.loadBalancer.execute (serviceName, 
new LoadBalancerRequest<ClientHttpResponse>() { 
@Override 
public ClientHttpResponse applylfinal ServiceInstance instance) 
throws Exception { 
HttpRequest serviceRequest =new ServiceRequestWrapper (request, 
instance); 
return execution.execute (serviceRequest, body); 


private class ServiceRequestWrapper extends HttpRequestWrapper { 
private final ServiceInstance instance; 


public ServiceRequestWrapper (HttpRequest request, ServicelInstance instance) { 
super (request); 
this.instance = instance; 


@Override 
public URI getURI() { 
URI uri = LoadBalancerIinterceptor.this.loadBalancer.reconstructURI ( 
this,instance getRequest () .getURI ()); 
return uri; 


} 
通过 源码 以 及 之 前 的 自动 化 配置 类 ， 我们 可 以 看 到 在 拦截 器 中 注入 
了 LoadBalancerClient 的 实现 。 当 一 个 被 @LoadBalanced 注 解 修饰 的 
RestTemplate 对 象 同 外 发 起 HTTP 请 求 时 ， 会 被 LoadBalancerInterceptor 类 
的 intercept 函 数 所 拦截 。 由 于 我 们 在 使 用 RestTemplate 时 采用 了 服务 名 作 
为 host， 所 以 直接 从 HttpRequest 的 URI 对 象 中 通过 getHost() 就 可 以 拿 





到 服务 名 ， 然 后 调用 execute 函 数 去 根据 服务 名 来 选择 实例 并 发 起 实际 的 
请 求 。 

分 析 到 这 里 ，LoadBalancerClient 还 只 是 一 个 抽象 的 负载 均衡 器 接 
口 ， 所 以 我 们 还 需要 找到 它 的 具体 实现 类 来 进一步 进行 分 析 。 通 过 查看 
Ribbon 的 源码 ， 可 以 很 容易 地 在 org.springframework.cloud.netflix.ribbon 
包 下 找到 对 应 的 实现 类 RibbonLoadBalancerClient。 


public <T> T execute (String serviceId, LoadBalancerRequest<T> request) throws 
IOException { 











ILoadBalancer loadBalancer = getLoadBalancer (serviceld); 
Server server = getServer (loadBalancer);} 
if (server == null) { 
throw new IllegalStateException("No instances available for " + servicelId); 
} 


RibbonServer ribbonServer = new RibbonServer(serviceld, server, 
isSecure (server, 


serviceld), serverIntrospector (servicelId) .getMetadata (server)); 


RibbonLoadBalancerContext context = this.clientFactory 
.getLoadBalancerContext (serviceld); 


RibbonSstatsRecorder statsRecorder = new RibbonStatsRecorder (context, server); 


ER 
T returnVal = request.apply (ribbonServer); 
statsRecorder.recordStats (returnVal); 
return returnVal; 

} 

catch (IOException ex) I 
statsRecorder.recordStats (ex); 
throw ex; 

} 

catch (Exception ex) { 
statsRecorder.recordStats (ex) ; 
ReflectionUtils.rethrowRuntimeException (ex); 

上 


return null; 


} 

可 以 看 到 ， 在 execute 函 数 的 实现 中 ， 第 一 步 做 的 就 是 通过 getServer 
根据 传 入 的 服务 名 serviceId 去 获得 具体 的 服务 实例 : 

protected Server getServer (ILoadBalancer loadBalancer) { 

if (loadBalancer==null) { 

return null; 

} 

return loadBalancer.chooseServer ("default") : 


} 


通过 getServer 函数 的 实现 源码 ， 我 们 可 以 看 到 这 里 获取 具体 服务 实 
例 的 时 候 并 没有 使 用 LoadBalancerClient 接 口中 的 choose 函 数 ， 而 是 使 用 
了 Netflix Ribbon 自 身 的 ILoadBalancer 接 口中 定义 的 chooseServer 函 数 。 

我 们 先 来 认识 一 下 这 个 ILoadBalancer 接 口 : 

public interface ILoadBalancer { 

public void addServers (List<Server> newServers) ; 

public Server chooseServer (Object key) ; 

public void markServerDown (Server server) ; 

public List<Server> getReachableServers (); 

public List<Server> getAllServers (); 


} 

可 以 看 到 ， 在 该 接口 中 定义 了 一 个 客户 端 负载 均衡 右 需 要 的 一 系列 
抽象 操作 〈 未 列举 过 期 函数 ) 。 

eaddServers: 问 负 载 均 衡器 中 维护 的 实例 列表 增加 服务 实例 。 

通过 某 种 策略 ， 从 负载 均衡 器 中 挑选 出 一 个 具体 的 
服务 实例 。 

emarkServerDown: 用 来 通知 和 标识 负载 均衡 器 中 某 个 具体 实例 已 
经 停 目 服务， 不然 负载 均衡 器 在 下 一 次 获取 服务 实例 清单 前 都 会 认为 服 
务实 例 均 是 正常 服务 的 。 

egetReachableServers: 获取 当前 正常 服务 的 实例 列表 。 

egetAllServers: 获取 所 有 已 知 的 服务 实例 列表 ， 包 括 正 常服 务 和 停 
止 服务 的 实例 。 

在 该 接口 定义 中 涉及 的 Server 对 象 定义 是 一 个 传统 的 服务 端 节 点 ， 在 
0 包括 host、port 以 及 一 些 
部 署 信息 等 。 

而 对 于 该 接口 的 实现 ， 我 们 整理 出 如 下 图 所 示 的 结构 。 可 以 看 到 ， 
BaseLoadBalancer 类 实现 了 基础 的 负载 均衡 ， 而 
DynamicServerListLoadBalancer 和 ZoneAwareLoadBalancer 在 负载 均衡 的 
策略 上 做 了 一 些 功 能 的 扩展 。 
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那么 在 整合 Ribbon 的 时 候 Spring Cloud 默认 采用 了 哪个 具体 实现 
呢 ? 我 们 通过 RibbonClientConfiguration ”配置 类 ， 可 以 知道 在 整合 时 默 
认 采 用 了 ZoneAwareLoadBalancer 来 实现 负载 均衡 器 。 

Bean 

@ConditionalOnMissingBean 

public ILoadBalancer ribbonLoadBalancer (IClientConfig config, 

ServerList<Server> serverList,ServerListFilter<Server> serverL istFilter, 

IRule rule,IPing ping) { 

ZoneAwareLoadBalancer<Server> 
balancer=LoadBalancerBuilder.newBuilder () 

.withClientConfig (config) .withRule (rule) .withPing (ping) 

.WithServerListFilter (serverListFilter) .withDynamicServerList (server 

.buildDynamicServerListLoadBalancer () ; 

return balancer:; 


} 
下 面 ， 我 们 再 回 到 RibbonLoadBalancerClient 的 execute 函数 逻辑 ， 


在 通过 ZoneAwareLoadBalancer 的 chooseServer 函数 获取 了 负载 均衡 策 
略 分 配 到 的 服务 实例 对 象 Server 之 后 ， 将 其 内 容 包 装 成 RibbonServer 对 象 
《该 对 象 除 了 存储 了 服务 实例 的 信息 之 外 ， 还 增加 了 服务 名 serviceId、 
是 人 否 需 要 使 用 HTTPS 等 其 他 信息 ) ， 然 后 使 用 该 对 象 再 回调 
LoadBalancerInterceptor 请 求 拦截 器 中 LoadBalancerRequest 的 apply (final 
ServiceInstance instance) 函数 ， 回 一 个 实际 的 有 具体 服务 实例 发 起 请 求 ， 
人 以 服务 名 为 host 的 URI 请 求 到 host:post 形 式 的 实际 访问 地 


在 apply (final ServiceInstance instance) 函数 中 传 入 的 ServiceInstance 
接口 对 象 是 对 服务 实例 的 抽象 定义 。 在 该 接口 中 暴露 了 服务 治理 系统 中 
每 个 服务 实例 需要 提供 的 一 些 基 本 信息 ， 比 如 serviceId、host、port 等 ， 
具体 定义 如 下 : 

public interface ServiceInstance { 

String getServiceld () ; 

String getHost () ; 

int getPort () ; 

boolean isSecure () ; 

URI getUri (); 

Map<String,String> getMetadata () ; 











} 

而 上 面 提 到 的 具体 包装 Server 服务 实例 的 RibbonServer 对 象 束 是 
ServiceInstance 接 口 的 实现 ， 可 以 看 到 它 除 了 包含 Server 对 象 之 外 ， 还 存 
储 了 服务 名 、 是 否 使 用 HTTPS 标 识 以 及 一 个 Map 类 型 的 元 数据 集合 。 

protected static class RibbonServer implements ServiceInstance { 

private final String serviceld; 

private final Server server; 

private final boolean secure; 

private Map<String,String> metadata; 

protected RibbonServer (String serviceld,Server server) { 

this (serviceld,server,false,Collections.<String, String> 
emptyMap () ) ; 

} 


protected RibbonServer (String serviceld,Server server,boolean secure, 
Map<String,String> metadata) { 

this.serviceld=serviceld:; 

this.server=server; 

this.secure=secure; 

this.metadata=metadata; 


} 

// 省 略 实现 ServiceInstance 的 一 些 获取 Server 信 息 的 get 函 数 

} 

那么 ”apply (final ServiceInstance instance〉 函数 在 接收 到 了 具体 


ServiceInstance 实 例 后 ， 是 如 何 通 过 LoadBalancerClient 接 口中 的 
reconstructURI 操 作 来 组 织 具体 请 求 地 址 的 呢 ? 





(DOverride 

public ClientHttpResponse apply (final ServiceInstance instance) 

throws Exception { 

HttpRequest serviceRequest=new 
ServiceRequestWrapper (request,instance) ; 

return execution.execute (serviceRequest,body) ; 

} 

从 apply 的 实现 中 ， 可 以 看 到 它 具 体 执行 的 时 候 ， 还 传 入 了 
ServiceRequestWrapper 对 象 ， 该 对 象 继 承 了 HttpRequestWrapper 并 重 写 
了 getURI 函 数 ， 重 写 后 的 getURI 通 过 调用 LoadBalancerClient 接 口 的 
reconstructURI 函 数 来 重新 构建 一 个 URI 来 进行 访问 。 

private class ServiceRequestWrapper extendshttpRequestWrapper { 

private final ServiceInstance instance; 


(DOverride 

public URI getURI () { 

URI uri=LoadBalancerInterceptor.this.loadBalancer.reconstructURI 
this.instance,getRequest () .getURI () ) ; 

return uri; 


} 

} 

在 LoadBalancerInterceptor 拦 截 器 中 ，ClientHttpRequestExecution 的 实 
例 具 体 执行 execution.execute (serviceReguest,body) 时 ， 会 调用 


InterceptingClientHttpRequest 下 InterceptingRequestExecution 类 的 execute 
函数 ， 具 体 实现 如 下 : 
public ClientHttpResponse execute (HttpRequest request,byte[]body) 
throws IOException { 
if (this.iterator.hasNext () ) { 
ClientHttpRequestInterceptor nextInterceptor=this.iterator.next (); 
return nextInterceptor.intercept (request,body,this) ; 
} 
else { 
ClientHttpRequest 
delegate=requestFactory.createRequest (request.getURI () ,request.getMetl 
delegate.getHeaders () .putAll (request.getHeaders () ) ; 
if (body.length > 0) { 
StreamUtils.copy (body,delegate.getBody () ) ; 


} 


return delegate.execute 〈) ; 


} 


} 

可 以 看 到 ， 在 创建 请 求 的 时 候 
requestFactory.createRequest (request. Set () ,request.getMethod () ) 
这 里 的 request.getURI () 会 调 用 之 前 介绍 的 ServiceRequestWrapper 对 象 
中 重 写 的 getURI 函 数 。 此 时 ， 它 就 会 使 用 RibbonLoad BalancerClient 中 实 
现 的 reconstructURI 来 组 织 具 体 请 求 的 服务 实例 地 址 。 

public URI reconstructURI (ServicelInstance instance,URI original ) { 

Assert.notNull (instance,"instance can not be null") : 

String serviceld=instance.getServiceld (); 

RibbonLoadBalancerContext context=this.clientFactory 

.getLoadBalancerContext (serviceld) ; 

Server server=new 
Server (instance.getHost () ,instance.getPort () ) ; 

boolean secure=isSecure (server,serviceld) ; 

URI uri=original; 

if (secure) { 

uri=UriComponentsBuilder.fromUTri (uri) .Scheme ("https") .build () 

} 

return context.reconstructURIWithServer (server,uri) ; 

} 

从 reconstructURI 函 数 中 我 们 可 以 看 到 ， 它 通 过 ServiceInstance 实 例 对 
象 的 serviceId， 从 SpringClientFactory 类 的 dientFactory 对 象 中 获取 对 应 
serviceld 的 负载 均衡 器 的 上 下 文 a 对 象 。 然 后 
根据 ServiceInstance 中 的 信息 来 构建 具体 服务 实例 信息 的 Server 对 象 ， 
并 使 用 RibbonLoadBalancerC ， 象 的 reconstructURIWithServer 函 数 
来 构建 服务 实例 的 URI。 

为 了 帮助 理解 ， 简 单 介 绍 一 下 上 面 提 到 的 SpringClientFactory 和 
RibbonLoadBalancerContext: 

eSpringClientFactory ”类 是 一 个 用 来 创建 客户 端 负载 均衡 器 的 工厂 
类 ， 该 工厂 类 会 为 每 一 个 不 同名 的 Ribbon 客 户 端 生成 不 同 的 Spring 上 下 
区 

eRibbonLoadBalancerContext 类 是 LoadBalancerContext 的 子 类 ， 该 类 
用 于 存储 一 些 被 负载 均衡 器 使 用 的 上 下 文 内 容 和 API 操作 

(reconstructURIWithServer 就 是 其 中 之 一 ) 。 








2 的 实现 中 我 们 可 以 看 到 ， 它 同 
reconstructURI 的 定义 类 似 。 只 是 reconstructURI 的 第 一 个 保存 有 具体 服务 
实例 的 参数 使 用 了 Si Cloud 定 义 的 ServiceInstance， 而 
reconstructURIWithServer 中 使 用 了 Netflix 中 定义 的 Server， 所 以 在 
RibbonLoadBalancerClient 实 现 reconstructURI 的 时 候 ， 做 了 一 次 转换 ， 
使 用 ServiceInstance 的 host 和 port 信 息 构 建 了 一 个 Server 对 象 来 给 
reconstructURIWithServer 使 用 。 从 reconstructURIWithServer 的 实现 逻辑 
中 ， 我 们 可 以 看 到 ， 它 从 Server 对 象 中 Os pont 上 县， 然后 根据 以 
服务 名 为 host 的 URI 对 象 original 中 获取 其 他 请 求 信 息 ， 将 两 者 内 容 进 行 
拼接 整合 ， 形 成 最 终 要 访问 的 服务 实例 的 具体 地 址 。 


public class LoadBalancerContext implements IClientConfigAware { 





public URI reconstructURIWithServer (Server server,URI original) { 
String host=server.getHost (); 

int port=server.getPort (); 

if (host.equals (original.getHost () ) 

RQ& port==original.getPort () ) { 

return original; 

} 

String scheme=original.getScheme (); 

if (scheme==null) { 
scheme=deriveSchemeAndPortFromPartialUri (original) .first (); 
} 

try { 

StringBuilder sb=new StringBuilder () ; 

sb.append (scheme) .append 〈"://") ; 

if (! Strings.isNullOrEmpty (original.getRawUserInfo () ) ) { 
sb.append (original.getRawUserInfo () ) .append ("@").; 

} 

sb.append (host) ; 

if (port >=0) { 

sb.append (":") .append (port); 

} 

sb.append (original.getRawPath () ) ; 

if (! Strings.isNullOrEmpty (original.getRawQuery () ) ) { 
sb.append ("?") .append (original.getRawQuery () ) ; 

} 


if (! Strings.isNullOrEmpty (original.getRawFragment () ) ) { 
sb.append ("#") .append (original.getRawFragment () ) ; 

} 

URI newURI=new URI (sb.toString () ) ; 

return newURI; 

} catch (URISyntaxException e) { 

throw new RuntimeException (e); 

} 

} 


} 

另外 ， 从 RibbonLoadBalancerClient 的 execute 函 数 逻 辑 中 ， 我 们 还 能 
看 到 在 回调 拦截 器 中 ， 执 行 具 体 的 请 求 之 后 ，Ribbon 还 通过 
RibbonStatsRecorder 对 象 对 服务 的 请 求 进 行 了 跟踪 记录 ， 这 里 不 再 展开 
说 明 ， 有 兴趣 的 读者 可 以 继续 研究 。 

分 析 到 这 里 ， 我 们 已 经 可 以 大 致 理 清 Spring Cloud Ribbon 中 实现 客户 
问 负 载 均衡 的 基本 脉络 ， 了 解 了 它 是 如 何 通过 ”LoadBalancerInterceptor 
拦截 器 对 RestTemplate 的 请 求 进行 拦截 ， 并 利用 Spring Cloud 的 负载 均衡 
器 LoadBalancerClient 将 以 逻辑 服务 名 为 host 的 URI 转换 成 具体 的 服务 实 
例 地 址 的 过 程 。 同 时 通过 分 析 LoadBalancerClient 的 Ribbon 实 现 
RibbonLoadBalancerClient， 可 以 知道 在 使 用 Ribbon 实 现 负 和 载 均衡 器 的 时 
候 ， 实 际 使 用 的 还 是 Ribbon 中 定义 的 ILoadBalancer 接 口 的 实现 ， 上 自动 化 
配置 会 采用 ZoneAwareLoadBalancer 的 实例 来 实现 客户 端 负载 均衡 。 


负载 均衡 器 


通过 之 前 的 分 析 ， 我 们 已 经 对 Spring Cloud 如 何 使 用 Ribbon 有 了 基 
本 的 了 解 。 虽 然 Spring Cloud 中 定义 了 LoadBalancerClient 作为 负载 均衡 
器 的 通用 接口 ， 并 且 针 对 Ribbon 实现 了 RibbonLoadBalancerClient， 但 
是 它 在 具体 实现 客户 端 负载 均衡 时 ， 是 通过 Ribbon 的 ILoadBalancer 接 
口 实现 的 。 在 上 一 节 进 行 分 析 时 候 ， 我 们 对 该 接口 的 实现 结构 已 经 做 了 
一 些 简单 的 介绍 ， 下 面 我 们 根据 ILoadBalancer 接 口 的 实现 类 逐个 看 看 它 
是 如 何 实 现 客户 端 负 载 均 衡 的 。 

AbstractLoadBalancer 

AbstractLoadBalancer 是 ILoadBalancer 接 口 的 抽象 实现 。 在 该 抽象 类 
中 定义 了 一 个 关于 服务 实例 的 分 组 枚 举 类 ServerGroup， 它 包含 以 下 三 种 
不 同类 型 。 

















eALL: 所 有 服务 实例 。 

eSTATUS_UP: 正常 服务 的 实例 。 

eSTATUS_NOT_UP: 停止 服务 的 实例 。 

另外 ， 还 实现 了 一 个 chooseServer () 函数 ， 该 函数 通过 调用 接口 中 
的 chooseServer (Object key) 实现 ， 其 中 参数 key 为 null， 表 示 在 选择 具 
体 服务 实例 时 忽略 key 的 条 件 判断 。 

最 后 ， 还 定义 了 两 个 抽象 函数 。 

egetServerList (ServerGroup serverGroup) : 定义 了 根据 分 组 类 型 来 
获取 不 同 的 服务 实例 的 列表 。 

egetLoadBalancerStats () : 定义 了 获取 LoadBalancerStats 对 象 的 方 
法 ，LoadBalancerStats 对 象 被 用 来 存储 负载 均衡 器 中 各 个 服务 实例 当前 
的 属性 和 统计 信息 。 这 些 信息 非常 有 有用， 我们 可 以 利用 这 些 信息 来 观察 
负载 均衡 器 的 运行 情况 ， 同 时 这 些 信息 也 是 用 来 制定 负载 均衡 策略 的 重 
要 依据 。 

public abstract class AbstractLoadBalancer implements ILoadBalancer { 

public enum ServerGroup{ 

ALL, 

STATUS_UP, 

STATUS_NOT_UP 

} 

public Server chooseServer () { 

return chooseServer (null) ; 

} 

public abstract List<Server> getServerList (ServerGroup 
serverGroup) ; 

public abstract LoadBalancerStats getLoadBalancerStats () ; 

} 

BaseLoadBalancer 

BaseLoadBalancer 类 是 Ribbon 负 和 载 均衡 器 的 基础 实现 类 ， 在 该 类 中 定 
义 了 很 多 关于 负载 均衡 器 相 关 的 基础 内 容 。 

e 定 义 并 维护 了 两 个 存储 服务 实例 Server 对 象 的 列表 。 一 个 用 于 存储 
所 有 服务 实例 的 清单 ， 一 个 用 于 存储 正常 服务 的 实例 清单 。 

@Monitor (name=PREFIX+"AllServerList",type=DataSourceType.INFC 

protected volatile List<Server> allServerList=Collections 

.SynchronizedList (new ArrayList<Server> () ) ; 

@Monitor (name=PREFIX+"UpServerList",type=DataSourceType.INFC 

protected volatile List<Server> upServerList=Collections 














.SynchronizedList (new ArrayList<Server> () ) ; 

ee 定义 了 之 前 我 们 提 到 的 用 来 存储 负载 均衡 器 各 服务 实例 属性 和 统计 
信息 的 LoadBalancerStats 对 象 。 

ee 定义 了 检查 服务 实例 是 否 正 常服 务 的 IPing 对 象 ， 在 
BaseLoadBalancer 中 默认 为 null， 需 要 在 构造 时 注入 它 的 具体 实现 。 

e 定 义 了 检查 服务 实例 操作 的 执行 策略 对 象 IPingStrategy， 在 
BaseLoadBalancer 中 默认 使 用 了 该 类 中 定义 的 静态 内 部 类 
SerialPingStrategy 实 现 。 根 据 源 码 ， 我 们 可 以 看 到 该 策略 采用 线性 遍历 
ping 服务 实例 的 方式 实现 检查 。 该 策略 在 当 IPing 的 实现 速度 不 理想 ， 或 
是 Server 列 表 过 大 时 ， 可 能 会 影响 系统 性 能 ， 这 时 候 需 要 通过 实现 
IPingStrategy 接口 并 重 写 pingServers (IPing ping,Server[]servers) 函数 
去 扩展 ping 的 执行 策略 。 

private static class SerialPingSstrategy implements IPingstrategy { 
@Override 














public boolean[] pingServers (IPing ping, Server[] servers) { 
int numCandidates = servers.length; 
boolean[] results = new boolean[numCandiqdates]; 


if (logger.isDebugEnabled()) { 
logger.debug ("LoadBalancer: PingTask executing [" 


+ numCandidates + "] servers configured"),; 
} 
for (int i = 0: i < nmCandidates; i++) { 
results[i] = false; 


ty 4 
if (Ping != null) 1 
results[i] = ping.isAlive (servers[i]); 
} 
} catch (Throwable 七 ) { 
logger .error ("Exception while pinging Server:" 
+ servers[i], t); 
} 
} 
return results; 
} 
} 


e 定 义 了 负载 均衡 的 处 理 规则 IRule 对 象 ， 从 BaseLoadBalancer 中 
chooseServer (Object key) 的 实现 源码 ， 我 们 可 以 知道 ， 负 载 均 衡器 实 
际 将 服务 实例 选择 任务 委托 给 了 IRule 实例 中 的 choose 函数 来 实现 。 而 
在 这 里 ， 默 认 初 始 化 了 RoundRobinRule 为 IRule 的 实现 对 象 。 
RoundRobinRule 实 现 了 最 基本 且 常 用 的 线性 负载 均衡 规则 。 

public Server chooseServer (Object key) { 


if (counter==null) { 
counter=createCounter () ; 
} 

counter.increment () ; 

if (rule==null ) { 

return null; 

} else { 

try { 

return rule.choose (key) ; 
} catch (Throwable t) { 
return null; 

} 

} 


} 

e 启 动 ping 任 务 : 在 BaseLoadBalancer 的 默认 构造 函数 中 ， 会 直接 局 
Te 于 定时 检查 Server 是 否 健康 的 任务 。 该 任务 默认 的 执行 间隔 为 
10 松 。 

人 实现 了 ILoadBalancer 接 口 定 义 的 负载 均衡 器 应 具备 以 下 一 系列 基本 
深 作 。 

国 addServers (List newServers) : 问 负 载 均 衡器 中 增加 新 的 服务 实例 
列表 ， 该 实现 将 原本 已 经 维护 着 的 所 有 服务 实例 清单 allServerList 和 新 
传 入 的 服务 实例 清单 newServers 都 加 入 到 newList 中 ， 然 后 通过 调用 
setServersList 函 数 对 newList 进 行 处 理 ， 在 BaseLoadBalancer 中 实现 的 时 
候 会 使 用 新 的 列表 和 窗 盖 旧 的 列表 。 而 之 后 介绍 的 几 个 扩展 实现 类 对 于 服 
务实 例 清单 更 新 的 优化 都 是 通过 对 setServersList 函 数 的 重 写 来 实现 的 。 

public void addServers (List<Server> newServers) { 

if (newServers !=null && newServers.size () > 0) { 

try { 

ArrayList<Server> newList=new ArrayList<Server> 〈) ; 
newList.addAll (allServerList) ; 

newList.addAll (newServers) ; 

setServersList (newList) ; 

} catch (Exception e) { 

logger.error ("Exception while adding Servers",e) ; 

} 

} 

} 











echooseServer (Object key) : 挑选 一 个 具体 的 服务 实例 ， 在 上 面 介 
绍 IRule 的 时 候 ， 己 经 做 了 说 明 ， 这 里 不 再 袭 述 。 

emarkServerDown (Server server) : 标记 某 个 服务 实例 暂停 服务 。 

public void markServerDown (Server server) { 

if (server==null) { 

return; 

} 

if (! server.isAlive () ) { 

return; 

} 

logger.error ("LoadBalancer: markServerDown called on[" 

+server.getlId () +"]"); 

server.setAlive (false) ; 

notifyServerStatusChangeListener (singleton (server) ) ; 


} 

egetReachableServers〈) : 获取 可 用 的 服务 实例 列表 。 由 于 
BaseLoadBalancer 中 单独 维护 了 一 个 正常 服务 的 实例 清单 ， 所 以 直接 返 
回 即 可 。 

public List<Server> getReachableServers () { 

return Collections.unmodifiableList (upServerList) ; 

} 

egetAllServers〈) : 获取 所 有 的 服务 实例 列表 。 由 于 
BaseLoadBalancer 中 单独 维护 了 一 个 所 有 服务 的 实例 清单 ， 所 以 也 直接 
返回 它 即 可 。 

public List<Server> getAllServers () { 

return Collections.unmodifiableList (allServerList) ; 

] 

Dynamic9erverListLoadBalancer 

DynamicServerListLoadBalancer 类 继承 于 BaseLoadBalancer 类 ， 它 
是 对 基础 负载 均衡 器 的 扩展 。 在 该 负载 均衡 器 中 ， 实 现 了 服务 实例 清单 
在 运行 期 的 动态 更 新 能 力 ; 同时 ， 它 还 具备 了 对 服务 实例 清单 的 过 滤 功 
能 ， 也 就 是 说 ,我 们 可 以 通过 过 滤器 来 选择 性 地 获取 一 批 服务 实例 清 
单 。 下 面 我 们 具体 来 看 看 在 该 类 中 增加 了 一 些 什么 内 容 。 

ServerList 

从 DynamicServerListLoadBalancer 的 成 员 定义 中 ， 我 们 蕊 上 可 以 发 
现 新 增 了 一 个 关于 服务 列表 的 操作 对 象 ServerList<T> serverListImpl。 其 
中 泛 型 T 从 类 名 中 对 于 TI 的 限定 DynamicServerListLoadBalancer<T extends 





Server> 可 以 获知 它 是 一 个 Server 的 子 类 ， 即 代表 了 一 个 具体 的 服务 实例 
的 扩展 类 。 而 ServerList 接 口 定 义 如 下 所 示 : 

public interface ServerList<T extends Server> { 

public List<T> getInitialListOfServers (); 

public List<T> getUpdatedListOfServers (); 

} 

它 定义 了 两 个 抽象 方法 : getInitialListOfServers 用 于 获取 初始 化 的 服 
务实 例 清单 ， 而 getUpdatedListOfServers 用 于 获取 更 新 的 服务 实例 清 
单 。 那 么 该 接口 的 实现 有 哪些 呢 ? 通过 搜索 源码 ， 我 们 可 以 整理 出 如 下 
图 所 示 的 结构 。 
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从 上 图 中 我 们 可 以 看 到 有 多 个 ServerL ist 的 实现 类 ， 那 么 在 
DynamicServerListLoadBalancer 中 的 ServerList 默 认 配 置 到 底 使 用 了 哪个 
从 体 实现 呢 ? 既然 在 该 负载 均衡 器 中 需要 实现 服务 实例 的 动态 更 新 ， 那 
么 势必 需要 Ribbon 具 备 访问 Eureka 来 获取 服务 实例 的 能 力 ， 所 以 我 们 从 
Spring Cloud 整合 Ribbon 与 Eureka 的 包 
org.Springframework.cloud.netflix.ribbon.eureka 下 进行 探索 ， 可 以 找到 配 
置 类 EurekaRibbonClientConfiguration， 在 该 类 中 可 以 找到 如 下 创建 
ServerList 实 例 的 内 容 : 
Bean 
@ConditionalOnMissingBean 
public ServerList<? > ribbonServerList 〈IClientConfig config) { 
DiscoveryEnabledNIWSServerList discoveryServerList=new 
DiscoveryEnabledNIWSServerList ( 
config) ; 
DomainExtractingServerList serverList=new 





DomainExtractingServerList ( 


discoveryServerLisbconfig,this.approximateZoneFromHostname) ; 
return serverList; 


} 

可 以 看 到 ， 这 里 创建 的 是 一 个 DomainExtractingServerList 实 例 ， 从 下 
面 它 的 源码 中 我 们 可 以 看 到 ， 在 它 内 部 还 定义 了 一 个 ServerList list。 同 
时 ，DomainExtractingServerList ”类 中 对 getlInitialListOfServers 和 
getUpdatedListOfServers 的 具体 实现 ， 其 实 委 托 给 了 内 部 定义 的 
ServerList list 对象 ， 而 该 对 象 是 通过 创建 ”DomainExtractingServerList 
时 ， 由 构造 函数 传 入 的 DiscoveryEnabledNIWSServerList 实 现 的 。 


Public class DomainExtractingServerList implements ServerList<DiscoveryEnabledServer> { 





private ServerList<DiscoveryEnabledServer> list; 
private IClientConfig clientConfig; 


private boolean approximateZoneFromHostname; 


public DomainExtractingServerList (ServerList<DiscoveryEnabledServer> list, 
IClientConfig clientConfig, boolean approximateZoneFromHostname) { 
thissliet = Jists 
this.clientConfig = clientConfig; 


this.approximateZoneFromHostname = approximateZoneFromHostname; 


} 


@Override 
public List<DiscoveryEnabledSserver> getInitialListOfServers() { 
List<DiscoveryEnabledServer> servers = setZones (this.1ist 
.getIinitialListOfServers () ) ; 
return servers; 


} 


QOverride 
public List<DiscoveryEnabledServer> getUpdatedListOfServers() 1{ 
List<DiscoveryEnabledServer> servers = setZzones (this.1ist 
.getUpdatedListOfServers ()); 
Leturn Serverss 


) 
那么 DiscoveryEnabledNIWSServerList 是 如 何 实现 这 两 个 服务 实例 获 
取 的 呢 ? 我 们 从 源码 中 可 以 看 到 这 两 个 方法 都 是 通过 该 关中 的 一 个 私有 


函数 obtainServersViaDiscovery 通 过 服务 发 现 机 制 来 实现 服务 实例 的 获取 
Hs 


(DOverride 
public List<DiscoveryEnabledServer> getInitialListOfServers () { 





return obtainServersViaDiscovery () ; 

} 

(DOverride 

public List<DiscoveryEnabledServer> getUpdatedListOfServers () { 

return obtainServersViaDiscovery (); 

} 

而 obtainServersViaDiscovery 的 实现 逻辑 如 下 所 示 ， 主 要 依靠 
EurekaClient 从 服务 注册 中 心中 获取 到 具体 的 服务 实例 InstanceInfo 列 表 

(EurekaClient 的 具体 实现 ， 我 们 在 分 析 Eureka 的 源码 时 已 经 做 了 详细 的 

介绍 ， 这 里 传 入 的 vipAddress 可 以 理解 为 逻辑 上 的 服务 名 ， 比 如 USER- 
SERVICE) 。 接 着 ， 对 这 些 服务 实例 进行 明 历 ， 将 状态 为 UP 正常 服 
务 ) 的 实例 转换 成 DiscoveryEnabledServer 对 象 ， 最 后 将 这 些 实例 组 织 成 
列表 返回 。 


private List<DiscoveryEnabledServer> obtainServersViaDiscovery() { 
List<DiscoveryEnabledServer> serverList = new 
ArrayList<DiscoveryEnabledServer> (); 





if (eurekaClientProvider == null || eurekaClientProvider.get() == null) 1 
logger.warn ("EurekaClient has not been initialized yet, returning an empty 
lot) 
return new ArrayList<DiscoveryEnabledServer>();} 


|: 


EurekaClient eurekaClient = eurekaClientProvider.get(); 
if (vipAddresses!=null)1 
for (String vipAddress : vipAddresses.split(",")) { 


List<InstanceInfo> ListofInstanceInfo = 
eurekaClient .getInstancesByVipAddress( 


vipAddress, isSecure, targetRegion); 
for (InstanceInfo ii : listOfInstanceInfo) { 
if (ii.getStatus () .equals (InstanceStatus.UP)) { 
// 省 上 咯 了 一 些 实例 信息 的 加 工 逻 辑 
DiscoveryEnabledServer des = new DiscoveryEnabledServer (ii, 
isSecure, shouldUseIpAddr); 
des.setZone (DiscoveryClient .getZone (ii)); 
serverList.add (des); 
} 
} 
if (serverList.size()>0 && prioritizeVipAddressBasedServers){ 
break; 
} 
} 
} 


return serverList; 


在 DiscoveryEnabledNIWSServerList 中 通过 EurekaClient 从 服务 注册 中 
心 获取 到 最 新 的 服务 实例 清单 后 ， 返 回 的 List 到 了 
DomainExtractingServerList 类 中 ， 将 继续 通过 setZones 函 数 进行 处 理 。 而 
这 里 的 处 理 具体 内 容 如 下 所 示 ， 主 要 完成 将 
DiscoveryEnabledNIWSServerList 返 回 的 List 列 表 中 的 元 素 ， 转 换 成 内 部 
定义 的 DiscoveryEnabledServer 的 子 类 对 象 DomainExtractingServer， 在 
该 对 象 的 构造 函数 中 将 为 服务 实例 对 象 设置 一 些 必 要 的 属性 ， 比 如 id、 
zone、isAliveFlag、readyToServe 等 信息 。 

private List<DiscoveryEnabledServer> 
setZones (List<DiscoveryEnabledServer> 

servers) { 

List<DiscoveryEnabledServer> result=new ArrayList<> (); 

boolean isSecure=this.clientConfig.getPropertyAsBoolean ( 

CommonClientConfigKey.IsSecure,Boolean.TRUE) ; 

boolean shouldUseIpAddr=this.clientConfig.getPropertyAsBoolean ( 

CommonClientConfigKey.UseIPAddrForServer,Boolean.FALSE) ; 

for (DiscoveryEnabledServer server : servers) { 

result.add (new 
DomainExtractingServer (server,isSecure,shouldUseIpAddr, 

this.approximateZoneFromHostname) ) ; 

} 

return result; 

} 

ServerListUpdater 

通过 上 面 的 分 析 我 们 已 经 知道 了 Ribbon 与 Eureka 整 合 后 ， 如 何 实 现 
从 Eureka ”Server 中 获取 服务 实例 清单 。 那 么 它 叉 是 如 何 触 发 向 Eureka 
Server 去 获取 服务 实例 清单 以 及 如 何在 获取 到 服务 实例 清单 后 更 新 本 地 
的 服务 实例 清单 的 呢 ? 继续 来 看 DynamicServerListLoadBalancer 中 的 实 
现 内 容 ， 我 们 可 以 很 容易 地 找到 下 面 定 义 的 天 于 ServerListUpdater 的 内 
容 : 

protected final ServerListUpdater.UpdateAction updateAction=new 
ServerListUpdater.UpdateAction () { 

(DOverride 

public void doUpdate () { 

updateListOfServers (); 

} 

忆 


protected volatile See OA ServVeIListUpdater; 

根据 该 接口 的 命名 ， 我 们 基本 就 能 猜 到 ， 这 个 对 象 实现 的 是 对 
ServerList 的 更 新 ， 所 以 可 以 称 它 为 “服务 更 新 副 *。 从 下 面 的 源码 中 可 以 
看 到 ， 在 ServerListUpdater 内 部 还 定义 了 一 个 UpdateAction 接 口 ， 上 耐 定 
a ia Le ee ed 

现 ， 其 中 doUpdate 实 现 的 内 容 束 是 对 ServerList 的 具 \ 体 更 新 操作 。 除 此 之 

外 , “服务 更 新 器 ”中 还 定义 了 一 系列 控制 它 和 获取 它 的 信息 的 操作 。 

public interface ServerListUpdater { 

public interface UpdateAction { 

void doUpdate 〈) ; 


} 
// 启 动 服务 更 新 器 ， 传 入 的 UpdateAction 对 象 为 更 新 操作 的 具体 实 
现 。 
void start (UpdateAction updateAction ) ; 
/停止 服务 更 新 器 
void stop () ; 
/获取 最 近 的 更 新 时 间 玲 
String getLastUpdate (); 
/获取 上 一 次 更 新 到 现在 的 时 间 间 隔 ， 单 位 为 蝶 秒 
long getDurationSinceLastUpdateMs 〈) ; 
/获取 错过 的 更 新 周期 数 
int getNumberMissedCycles (); 
/获取 核心 线程 数 
int getCoreThreads (); 
} 
而 ServerListUpdater 的 实现 类 不 多 ， 具 体 如 下 图 所 示 。 





WW ServerListUpdater 
a 四 


© EurekaNotificationServerListUpdater &) PollingServerListUpdater 
根据 两 个 类 的 注释 ， 我 们 可 以 很 容易 地 知道 它们 的 作用 。 


ePollingServerListUpdater: 动态 服务 列表 更 新 的 默认 策略 ， 也 就 是 
说 ，DynamicServerListLoadBalancer 负载 均衡 器 中 的 默认 实现 就 是 它 ， 


它 通 过 定时 任务 的 方式 进行 服务 列表 的 更 新 。 

eEurekaNotificationServerListUpdater: 该 更 新 器 也 可 服务 于 
DynamicServerListLoadBalancer 负 载 均 衡器 ， 但 是 它 的 触发 机 制 与 
PollingServerListUpdater 不 同 ， 它 需要 利用 Eureka 的 事件 监听 器 来 驱动 服 
务 列表 的 更 新 操作 。 

下 面 我 们 来 详细 看 看 它 默认 实现 的 PollingServerListUpdater。 先 从 用 
于 局 动 * 服 务 更 新 器 ?的 start 函 数 源码 看 起 ， 有 具体 如 下 。 我 们 可 以 看 到 
start 函 数 的 实现 内 容 验证 了 之 前 提 到 的 : 以 定时 任务 的 方式 进行 服务 列 
表 的 更 新 。 它 先 创建 了 一 个 Runnable 的 线程 实现 ， 在 该 实现 中 调用 了 上 
面 提 到 的 具体 更 新 服务 实例 列表 的 方法 updateAction.doUpdate () ， 最 
后 再 为 这 个 Runnable 线 程 实现 启动 了 一 个 定时 任务 来 执行 。 


QOverride 








public synchronized void start (final UpdateAction updateAction) { 
if (isActive.compareAndSet (false, true)) { 
final Runnable wrapperRunnable = new Runnable() I 
QOverride 
public void run() { 
if (!isActive.get()) 1 
if (scheduledFuture != null) { 
ScheduledFuture .cancel (true); 
} 
return; 
} 
Dry 
updateAction.doUpdate (); 
lastUpdated = System.CurrentTimeMi1llis(): 
} catch (Exception e) 1{ 
logger.warn("Failed one update cycle", e); 


} 
}; 


scheduledFuture = getRefreshExecutor() .scheduleWithFixedDelay!( 
wrapperRunnable, 
initialDelayMs, 
refreshIintervalMs, 
TimeUnit .MILLISECONDS 

); 

} else { 
logger.infol("Already active, no-op"); 


b, 


) 

继续 看 PollingServerListUpdater 的 其 他 内 容 ， 我 们 可 以 找到 用 于 局 
动 定时 任务 的 两 个 重要 参数 initialDelayMs 和 refreshIntervalMs 的 默认 定义 
分 别 为 1000 和 30*1000， 单 位 为 野 秒 。 也 就 是 说 ， 更 新 服务 实例 在 初始 


化 之 后 延迟 1 秒 后 开始 执行 ， 并 以 30 秒 为 周期 重复 执行 。 除 了 这 些 内 容 
之 外 ， 还 能 看 到 它 还 会 记录 最 后 更 新 时 间 、 是 否 存 活 等 信息 ， 同 时 也 实 
现 了 ServerListUpdater 中 定义 的 一 些 其 他 操作 内 容 ， 这 些 操作 相对 比较 
简单 ， 这 里 不 再 具体 说 明 ， 有 兴趣 的 读者 可 以 自己 碍 看 源码 了 解 其 实现 
原理 。 

ServerListFilter 

在 了 解 了 更 新 服务 实例 的 定时 任务 是 如 何 局 动 的 之 后 ， 我 们 回 到 
updateAction.doUpdate () 调用 的 具体 实现 位 置 ， 在 
DynamicServerListLoadBalancer 中 ， 它 的 实际 实现 委托 给 了 
updateListOfServers 函 数 ， 有 共 体 实现 如 下 : 

public void updateListOfServers () { 

List<T> servers=new ArrayList<T> 〈) ; 

if (serverListImpl] !=null ) { 

servers=serverListImpl.getUpdatedListOfServers (); 

LOGGER.debug ("List of Servers for {} obtained from Discovery client: 
{}", 

getIdentifier () ,servers) ; 

if (filter !=null) { 

servers=filter.getFilteredListOfServers (servers) ; 

LOGGER.debug ("Filtered List of Servers for {} obtained from 
Discovery 

client: {}", 

getIdentifier () ,servers) ; 

| 

} 


updateAllServerList (servers) ; 














} 

可 以 看 到 ， 这 里 终于 用 到 了 之 前 提 到 的 ServerList 的 
getUpdatedListOfServers〈) ， 通 过 之 前 的 介绍 已 经 知道 这 一 步 实 现 了 
从 Eureka Server 中 获取 服务 可 用 实例 的 列表 。 在 获得 了 服务 实例 列表 之 
后 ， 这 里 又 将 引入 一 个 新 的 对 象 filter， 扎 溯 该 对 象 的 定义 ， 我 们 可 以 找 
到 它 是 ServerListFilter 定 义 的 。 

ServerListFilter 接 口 非常 简单 ， 该 接口 中 定义 了 一 个 方法 List 
getFilteredListOfServers (List servers) ， 主 要 用 于 实现 对 服务 实例 列表 
的 过 滤 ， 通 过 传 入 的 服务 实例 清单 ， 根 据 一 些 规则 返回 过 滤 后 的 服务 实 
例 清单 。 访 接口 的 实现 如 下 图 所 示 。 


ServerListFilter | 
入 


AbstractServerListFilter 


| 


© ZoneAffinityServerListFilter 
| 


© ZonePreferenceServerListFilter | © DefaultNIWSServerListFilter | ©) ServerListSubsetFilter 





其 中 ， 除 了 ZonePreferenceServerListFilter 的 实现 是 Spring Cloud 
Ribbon 中 对 Netflix Ribbon 的 扩展 实现 外 ， 其 他 均 是 Netflix Ribbon 中 的 原 
生 实 现 类 。 下 面 ， 我 们 可 以 分 别 看 看 这 些 过 滤器 实现 都 有 什么 特点 。 

eAbstractServerListFilter: 这 是 一 个 抽象 过 滤器 ， 在 这 里 定义 了 过 小 
时 需要 的 一 个 重要 依据 对 象 LoadBalancerStats， 我 们 在 之 前 介绍 过 ， 该 
对 象 存储 了 关于 负载 均衡 器 的 一 些 属性 和 统计 信息 等 。 

public abstract class AbstractServerListFilter<T extends Server> 
implements ServerL istFilter<T> { 

private volatile LoadBalancerStats stats; 

public void setLoadBalancerStats (LoadBalancerStats stats) { 

this.stats=stats; 

} 

public LoadBalancerStats getLoadBalancerStats () { 

return stats; 

] 

} 

eZoneAffinityServerListFilter: 该 过 滤 占 基于 “区 域 感知 (Zone 
Affinity) ”的 方式 实现 服务 实例 的 过 小 ， 也 就 是 说 ， 它 会 根据 提供 服务 
的 实例 所 处 的 区 域 (Zone) 与 消费 者 自身 的 所 处 区 域 (Zone) 进行 比 
较 ， 过 滤 掉 那些 不 是 同 处 一 个 区 域 的 实例 。 

public List<T> getFilteredListOfServers (List<T> servers) { 

if (zone !=null && (zoneAffinity || zoneExclusive) && servers !=null 
&& 

servers.size () > 0) { 

List<T> filteredServers=Lists.newArrayList (Iterables.filter ( 
servers,this.zoneAffinityPredicate.getServerOnlyPredicate () ) ) ; 








if (shouldEnableZoneAffinity 〈filteredServers) ) { 
return filteredServers; 

} else if (zoneAffinity) { 
overrideCounter.increment () ; 

} 

} 


return servers,; 


} 

从 上 面 的 源码 中 我 们 可 以 看 到 ， 对 于 服务 实例 列表 的 过 小 是 通过 
Iterables.filter (servers,this.zoneAffinityPredicate.getServerOnlyPredicate ( 
来 实现 的 ， 其 中 判断 依据 由 ZoneAffinityPredicate 实现 服务 实例 与 消费 
者 的 ”Zone 比 较 。 而 在 过 滤 之 后 ， 这 里 并 不 会 马上 返回 过 滤 的 结果 ， 而 
是 通过 shouldEnableZoneAffinity 孙 数 来 判断 是 否 要 启用 “区 域 感知 ”的 功 
能 。 从 下 面 shouldEnableZoneAffinity 的 实现 中 ， 我 们 可 以 看 到 ， 它 使 用 
了 LoadBalancerStats 的 getZoneSnapshot 方 法 来 获取 这 些 过 滤 后 的 同 区 域 
实例 的 基础 指标 《包含 实例 数量 、 断 路 器 断 开 数 、 活 动 请 求 数 、 实 例 平 
均 负 载 等 ) ， 根 据 一 系列 的 算法 求 出 下 面 的 几 个 评价 值 并 与 设置 的 国 值 
进行 对 比 《〈 下 面 的 为 默认 值 ) ， 大 有 一 个 条 件 符 合 ， 就 不 局 用" 区域 感 
知 ” 过 滤 的 服务 实例 清单 。 这 一 算法 实现 为 集群 出 现 区 域 故障 时 ， 依 然 
可 以 依靠 其 他 区 域 的 实例 进行 正常 服务 提供 了 完善 的 高 可 用 保障 。 同 
时 ， 通 过 这 里 的 介绍 ， 我 们 也 可 以 关联 着 来 理解 之 前 介绍 Eureka 的 时 候 
提 到 的 对 于 区 域 分 配 设计 来 保证 跨 区 域 故 障 的 高 可 用 问题 。 

eblackOutServerPercentage: 故障 实例 百分比 《断路 器 断 开 数 /实例 数 
量 ) >=0.8。 

eactiveReqeustsPerServer: 实例 平均 负载 >=0.6。 

eavailableServers: 可 用 实例 数 〈 实 例 数 量 -断路 器 断 开 数 ) < 2。 

private boolean shouldEnableZoneAffinity (List<T> filtered) { 

if (! zoneAffinity && ! zoneExclusive) { 

return false; 














if (zoneExclusive) { 

return true; 

} 

LoadBalancerStats stats=getLoadBalancerStats (); 
if (stats==null) { 

return zoneAffinity; 

} else { 


logger.debug ("Determining if zone affinity should be enabled with 
given server list: {}",filtered) ; 

ZoneSnapshot snapshot=stats.getZoneSnapshot (filtered ) ; 

double loadPerServer=snapshot.getLoadPerServer (); 

int instanceCount=snapshot.getInstanceCount (); 

int circuitBreakerTrippedCount=snapshot.getCircuitTrippedCount (); 

if ( ( (double) circuitBreakerTrippedCount) /instanceCount >= 

blackOutServerPercentageThreshold.get () 

| loadPerServer >=activeRedeustsPerServerThreshold.get () 

| CinstanceCount-circuitBreakerTrippedCount) < 

availableServersThreshold.get () ) { 

logger.debug ("zoneAffinity is overriden.blackOutServerPercentage: {}, 

activeRegqeustsPerServer: {},availableServers: {}", 

new Object[]{ (double) circuitBreakerTrippedCount /instanceCount， 

loadPerServer,instanceCount-circuitBreakerTrippedCount} ) ; 

return false; 

} else { 

return true; 

} 

} 

} 

eDefaultNIWSServerListFilter: 该 过 滤器 完全 继承 自 
ZoneAffinityServerListFilter， 是 默认 的 NIWS (Netflix Internal Web 
Service) 过 滤器 。 

eServerListSubsetFilter: 该 过 滤器 也 继承 自 
ZoneAffinityServerListFilter， 它 非常 适用 于 拥有 大 规模 服务 器 集群 《上 
百 或 更 多 ) 的 系统 。 因 为 它 可 以 产生 一 个 “区 域 感 知 ” 结 果 的 子 集 列表 ， 
同时 它 还 能 够 通过 比较 服务 实例 的 通信 失败 数量 和 并 发 连接 数 来 判定 该 
服务 是 否 健康 来 选择 性 地 从 服务 实例 列表 中 剔除 那些 相对 不 够 健康 的 实 
例 。 该 过 滤器 的 实现 主要 分 为 以 下 三 步 : 

1. 获 取 “ 区 域 感知 ”的 过 小 结果 ， 作 为 候选 的 服务 实例 清单 。 

2. 从 当前 消费 者 维护 的 服务 实例 子 集中 剔除 那些 相对 不 够 健康 的 实 
例 《 同 时 也 将 这 些 实例 从 候选 清单 中 剔除 ， 防 止 第 三 步 的 时 候 叉 被 选 
入 ) ， 不 够 健康 的 标准 如 下 所 示 。 
a. 服 务实 例 的 并 发 连接 数 超过 客户 端 配置 的 值 ， 默 认为 0， 配 置 参 数 


<clientName>.<nameSpace>.ServerListSubsetFilter.eliminat 








ionConnectionThresold。 

b. 服 务实 例 的 失败 数 超过 客户 端 配置 的 值 ， 默 认为 0， 配 置 参数 为 

<clientName>.<nameSpace>.ServerListSubsetFilter.eliminat 

ionFailureThresold。 

c. 如 宋 按 符合 上 面 任 一 规则 的 服务 实例 剔除 后 ， 剔 除 比例 小 于 客户 端 
默认 配置 的 百分比 ， 默 认为 0.1 (10%) ， 配 置 参数 为 <clientName>. 
<nameSpace>.ServerListSubsetFilter.forceEliminatePercent， 那 么 就 先 对 剩 
下 的 实例 列表 进行 健康 排序 ， 再 从 最 不 健康 的 实例 进行 剔除 ， 直 到 达到 
配置 的 剔除 百分比 。 

3. 在 完成 剔除 后 ， 清 单 已 经 少 了 至 少 10% 《默认 值 ) 的 服务 实例 ， 最 
后 通过 随机 的 方式 从 候选 清单 中 选 出 一 批 实 例 加 入 到 清单 中 ， 以 保持 服 
务实 例子 集 与 原来 的 数量 一 致 ， 而 默认 的 实例 子 集 数 量 为 20， 其 配置 参 
数 为 <clientName>.<nameSpace>.ServerListSubsetFilter.size。 

eZonePreferenceServerListFilter:Spring Cloud 整合 时 新 增 的 过 滤器 。 
知 使 用 Spring Cloud 整 合 Eureka 和 Ribbon 时 会 默认 使 用 该 过 滤器。 它 实现 
了 通过 配置 或 者 Eureka 实 例 元 数据 的 所 属 区 域 (Zone) 来 过 滤 出 同 区 域 
的 服务 实例 。 如 下 面 的 源码 所 示 ， 它 的 实现 非常 人 简单， 首先 通过 父 类 
ZoneAffinityServerListFilter 的 过 滤器 来 获得 “区 域 感知 ”的 服务 实例 列 
表 ， 然 后 过 历 这 个 结 采 ， 取 出 根据 消费 者 配置 预 设 的 区 域 Zone 来 进行 
过 滤 ， 如 果 过 沽 的 结果 是 空 就 直接 返回 父 类 获取 的 结果 ， 如 果 不 为 空 就 
返回 通过 消费 者 配置 的 Zone 过 小 后 的 结果 。 

(DOverride 

public List<Server> getFilteredListOfServers (List<Server> servers) { 

List<Server> output=super.getFilteredListOfServers (servers) ; 

if (this.zone !=null && output.size () ==servers.size () ) { 

List<Server> local=new ArrayList<Server> (); 

for (Server server : output) { 

if (this.zone.equalsIgnoreCase (server.getZone () ) ) { 

local.add (server) ; 


} 

















} 

if (!localisEmpty () ) { 
return local; 

} 

} 

return output; 


} 


ZoneAwareLoadBalancer 

ZoneAwareLoadBalancer 负载 均衡 器 是 对 
DynamicServerListLoadBalancer 的 扩展 。 在 
DynamicServerListLoadBalancer 中 ， 我 们 可 以 看 到 它 并 没有 重 写 选择 具 
体 服 务实 例 的 chooseServer 函 数 ， 所 以 它 依 然 会 采用 在 BaseLoadBalancer 
中 实现 的 算法 。 使 用 RoundRobinRule 规则 ， 以 线性 轮 询 的 方式 来 选择 
调用 的 服务 实例 ， 该 算法 实现 简单 并 没有 区 域 《Zone) 的 概念 ， 所 以 它 
会 把 所 有 实例 视 为 一 个 Zone 下 的 节点 来 看 待 ， 这 样 就 会 周期 性 地 产生 路 
区 域 (Zone) 访问 的 情况 ， 由 于 路 区 域 会 产生 更 高 的 延迟 ， 这 些 实例 主 
要 以 防止 区 域 性 故障 实现 高 可 用 为 目的 而 不 能 作为 常规 访问 的 实例 ， 所 
以 在 多 区 域 部 普 的 情况 下 会 有 一 定 的 性 能 问题 ， 而 该 负载 均衡 器 则 可 以 
避免 这 样 的 问题 。 那 么 它 是 如 何 实现 的 呢 ? 

首先 ， 在 ZoneAwareLoadBalancer 中 ， 我 们 可 以 发 现 ， 它 并 没有 重 写 
setServersList， 说 明 实 现 服 务实 例 清单 的 更 新 主 逻 辑 没有 修改 。 但 是 我 
们 可 以 发 现 它 重 写 了 这 个 函数 
setServerListForZones (Map<String,List<Server>>zoneServersMap) 。 看 
到 这 里 可 能 会 有 一 些 陌生 ， 因 为 它 并 不 是 接口 中 定义 的 必 备 函数 ， 所 以 
我 们 不 妨 去 父 类 DynamicServerListLoadBalancer 中 寻找 一 下 该 函数 ， 我 
们 可 以 找到 下 面 的 定义 : 

public void setServersList (Listlsrv) { 

super.setServersList (lsrv) ; 

List<T> serverList= (List<T>) lsrv; 

Map<String,List<Server>> serversInZones=new 
HashMap<String,List<Server>> 〈) ; 





setServerListForZones (serversInZones) ; 

} 

protected void setServerListForZones (Map<String,List<Server>> 
zoneServersMap) { 

LOGGER.debug ("Setting server list for zones: {}",zoneServersMap) ; 

getLoadBalancerStats () .updateZoneServerMapping (zoneServersMap 

} 

setServerListForZones 函数 的 调用 位 于 更 新 服务 实例 清单 函数 
setServersList 的 最 后 ， 同 时 从 其 实现 的 内 容 来 看 ， 它 在 父 类 
DynamicServerListLoadBalancer 中 的 作用 是 根据 按 区 域 Zone 分 组 的 实例 
列表 ， 为 负载 均衡 器 中 的 LoadBalancerStats 对 象 创 建 ZoneStats 并 放 入 
Map zoneStatsMap 集 合 中 ， 每 一 个 区 域 Zone 对 应 一 个 ZoneStats， 它 用 于 





存储 每 个 Zone 的 一 些 状 态 和 统计 信息 。 

在 ZoneAwareLoadBalancer 中 对 setServerListForZones 的 重 写 如 下 : 

protected void setServerListForZones (Map<String,List<Server>> 
zoneServersMap) { 

super.setServerListForZones (zoneServersMap) ; 

if (balancers==null ) { 

balancers=new ConcurrentHash Map<String,BaseLoadBalancer> () ; 

} 

for (Map.Entry<String,List<Server>> entry: 
zoneServersMap.entrySet () ) { 

String zone=entry.getKey () .toLowerCase 〈) ; 

getLoadBalancer (zone) .setServersList (entry.getValue () ) ; 

} 

for (Map.Entry<String,BaseLoadBalancer> existingLBEntry: 
balancers.entrySet () ) { 

if (! 
zoneServersMap.keySet () .contains (existingLBEntry.getKey () ) ) { 

existingLBEntry.getValue () .setServersList (Collections.emptyList () 

} 

} 


} 

可 以 看 到 ， 在 该 实现 中 创建 了 一 个 ”ConcurrentHashMap 〈) 类 型 的 
balancers 对 象 ， 它 将 用 来 存储 每 个 Zone 区 域 对 应 的 负载 均衡 器 。 而 有 具体 
的 负载 均衡 器 的 创建 则 是 通过 在 下 面 的 第 一 个 循环 中 调用 
getLoadBalancer 函 数 来 完成 ， 同 时 在 创建 负载 均衡 器 的 时 候 会 创建 它 的 
规则 《如 果 当 前 实现 中 没有 IRule 的 实例 ， 就 创建 一 个 
AvailabilityFilteringRule 规 则 ;， 如 果 已 经 有 具体 实例 ， 束 元 隆 一 个 ) 。 在 
创建 完 负载 均衡 器 后 又 马上 调用 setServersList 函 数 为 其 设置 对 应 Zone 区 
域 的 实例 清单 。 而 第 二 个 循环 则 是 对 Zone 区域 中 实例 清单 的 检查 ， 看 
看 是 否 有 Zone ”区域 下 已 经 没有 实例 了 ， 是 的 话 就 将 balancers 中 对 应 
Zone 区 域 的 实例 列表 清空 ， 该 操作 的 作用 是 为 了 后 续 选 择 节 点 时 ， 防 止 
过 时 的 Zone 区 域 统计 信息 干扰 具体 实例 的 选择 算法 。 

在 了 解 了 该 负载 均衡 器 是 如 何 扩展 服务 实例 清单 的 实现 后 ， 我 们 来 
具体 看 看 它 是 如 何 挑选 服务 实例 ， 来 实现 对 区 域 的 识别 的 : 




















public Server chooseServer (Object key) { 

it (!ENABLED.get() || getLoadBalancerStats() .getAvailableZones() .size() <= 1) { 
logger.debug ("Zone aware logic disabled or there is only one zone"); 
return super.chooseServer (key); 

} 

Server server = null; 

try 
LoadBalancerstats lbStats = getLoadBalancerstats(); 
Map<String, ZoneSnapshot> ZoneSnapshot = ZoneAvoidanceRule.createSnapshot 

(lbstats); 

logger.debug("Zone snapshots: {}", zoneSnapshot); 


Set<String> availableZones = ZoneAvoidanceRule.getAvailablezones 
(zoneSsnapshot, triggeringLoad.get (), triggeringBlackoutPercentage.get ()); 
logger.debug("Available zones: {}", availableZones); 
if (availableZones != null && availableZones.size() < 
ZoneSnapshot .keySet () .size()) { 
String zone = ZoneAvoidanceRule.randomChooseZone (zoneSnapshot, 
availableZones); 
logger.debug ("Zone chosen: {}", zone); 
if (zone != null) 1 
BaseLoadBalancer zoneLoadBalancer = getLoadBalancer (zone); 
server = zoneLoadBalancer.chooseServer (key); 
} 
} 
} catch (Throwable e) 1{ 
logger.error ("Unexpected exception when choosing server using zone aware 
logic", e); 
} 
if (server != null) { 
return server; 
} else { 
logger.debug ("Zone avoidance logic is not invoked."); 
return super.chooseServer (key); 
} 


} 

从 源码 中 我 们 可 以 看 到 ， 只 有 当 负 载 均衡 器 中 维护 的 实例 所 属 的 
Zone 区 域 的 个 数 大 于 1 的 时 候 才 会 执行 这 里 的 选择 策略 ， 人 否则 还 是 将 使 
用 父 类 的 实现 。 当 Zone 区 域 的 个 数 大 于 1 的 时 候 ， 它 的 实现 步骤 如 下 所 
示 。 

e 调 用 ZoneAvoidanceRule 中 的 静态 方法 createSnapshot (lbStats) ， 为 
当前 负载 均衡 器 中 所 有 的 Zone 区 域 分 别 创建 快照 ， 保 存在 Map 
zoneSnapshot 中 ， 这 些 快照 中 的 数据 将 用 于 后 续 的 算法 。 

e 调 用 ZoneAvoidanceRule 中 的 静态 方法 
getAvailableZones (zoneSnapshot,triggeringLoad.get () ,triggeringBlackou 
来 获取 可 用 的 Zone 区 域 集合 ， 在 该 函数 中 会 通过 Zone 区 域 快 照 中 的 统计 
数据 来 实现 可 用 区 的 挑选 。 





四 首先 它 会 剔除 符合 这 些 规则 的 Zone 区 域 : 所 属实 例 数 为 零 的 Zone 
区 域 ，Zone 区 域内 实例 的 平均 负载 小 于 零 ， 或 者 实例 故障 率 〈 上 断路 器 断 
开 次 数 /实例 数 〉 大 于 等 于 国 值 〈 默 认为 0.99999) 。 

四 然后 根据 Zone 区 域 的 实例 平均 负载 计算 出 最 差 的 Zone 区 域 ， 这 里 
的 最 大 指 的 是 实例 平均 负载 最 高 的 Zone 区 域 。 

国 如 果 在 上 面 的 过 程 中 没有 符合 剔除 要 求 的 区 域 ， 同 时 实例 最 大 平均 
负载 小 于 国 值 〈 默 认为 20%) ， 就 直接 返回 所 有 Zone 区 域 为 可 用 区 域 。 
否则 ， 从 最 坏 Zone 区 域 集合 中 随机 选择 一 个 ， 将 它 从 可 用 Zone 区 域 集合 
中 剔除 。 

e 当 获得 的 可 用 Zone 区 域 集 合 不 为 空 ， 并 且 个 数 小 于 Zone 区 域 总 
数 ， 就 随机 选择 一 个 Zone 区 域 。 

e 在 确定 了 某 个 Zone 区 域 后 ， 则 获取 了 对 应 Zone 区 域 的 服务 均衡 
器 ， 并 调用 chooseServer 来 选择 具体 的 服务 实例 ， 而 在 chooseServer 中 
将 使 用 IRule 接 口 的 choose 函数 来 选择 具体 的 服务 实例 。 在 这 里 ，IRule 
接口 的 实现 会 使 用 ZoneAvoidanceRule 来 挑选 出 具体 的 服务 实例 。 

关于 ZoneAvoidanceRule 的 策略 以 及 其 他 一 些 还 未 提 到 的 负载 均衡 
策略 ， 我 们 将 在 下 一 节 做 更 加 详细 的 解读 。 


名 载 均 衡 和 大 大 上 略 


通过 上 面 的 源码 解读 ， 我 们 已 经 对 Ribbon 实 现 的 负载 均衡 器 以 及 其 
中 包含 的 服务 实例 过 小 器、 服务 实例 信息 的 存储 对 象 、 区 域 的 信息 快照 
等 都 有 了 深入 的 认识 和 理解 ， 但 是 对 于 猴 载 均衡 器 中 的 服务 实例 选择 策 
略 只 是 讲解 了 几 个 默认 实现 的 内 容 ， 而 对 于 IRule 的 其 他 实现 还 没有 详 
细 解 读 ， 下 面 我 们 来 看 看 在 Ribbon 中 都 提供 了 哪些 负载 均衡 的 策略 实 
现 。 

如 下 图 所 示 ， 可 以 看 到 在 Ribbon 中 实现 了 非常 多 的 选择 策略 ， 其 中 
也 包含 了 我 们 在 前 面 内 容 中 提 到 过 的 RoundRobinRule 和 
ZoneAvoidanceRule。 下 面 我 们 来 详细 解读 一 下 IRule 接 口 的 各 个 实现 。 
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AbstractLoadBalancerRule 

负载 均衡 策略 的 抽象 类 ， 在 该 抽象 类 中 定义 了 负载 均衡 器 
ILoadBalancer 对 象 ， 访 对象 能 够 在 具体 实现 选择 服务 策略 时 ， 获 取 到 一 
些 负 载 均 衡器 中 维护 的 信息 来 作为 分 配 依据 ， 并 以 此 设计 一 些 算法 来 实 
现 针 对 特定 场景 的 高 效 策 略 。 

public abstract dclass AbstractLoadBalancerRule implements 
IRule,IClientConfigAware { 

private ILoadBalancer lb; 

(DOverride 

public void setLoadBalancer (ILoadBalancer lb) { 

this.lb=lb; 

} 

(DOverride 

public ILoadBalancer getLoadBalancer () { 

return ]b; 

} 

} 

RandomRule 

该 策略 实现 了 从 服务 实例 清单 中 随机 选择 一 个 服务 实例 的 功能 。 它 
的 有 具体 实现 如 下 ， 可 以 看 到 IRule 接口 的 choose (Object key) 函数 实 
现 ， 委 托 给 了 该 类 中 的 choose (ILoadBalancer lb,Object key) ， 该 方法 
增加 了 一 个 负载 均衡 器 对 象 的 参数 。 从 具体 的 实现 上 看 ， 它 会 使 用 传 入 
的 负载 均衡 器 来 获得 可 用 实例 列表 upList 和 所 有 实例 列表 allList， 并 通 
过 rand.nextInt 〈serverCount) 函数 来 获取 一 个 随机 数 ， 并 将 该 随机 数 作 
为 upList 的 索引 值 来 返回 具体 实例 。 同 时 ， 具 体 的 选择 逻辑 在 一 个 














while (server==null) 循环 之 内 ， 而 根据 选择 逻辑 的 实现 ， 正 常情 况 下 
每 次 选择 都 应 该 选 出 一 个 服务 实例 ， 如 果 出 现 死 循环 获取 不 到 服务 实例 
时 ， 则 很 有 可 能 存在 并 发 的 Bug。 


@Override 





public Server choose (Object key) I 
return choose(getLoadBalancer(), key); 


} 
public Server choose (ILoadBalancer lb, Object key) { 


Server server = null; 
while (server == null) { 
if (Thread.interrupted()) { 
return null; 
} 
List<Server> upList = lb.getReachableServers(); 
List<Server> allList = lb.getAllServers(); 
int serverCount = allList.size(); 
if (serverCount == 0) 1 
return null; 
} 
int index = rand.nextInt (serverCount); 
server = upList.get (index); 
if (server == null) f 
Thread.yield(); 
continue; 
} 
if (server.isAlive()) 1{ 
return (server); 
} 
server = null; 
Thread.yield(); 
} 
return Server? 


} 
RoundRobinRule 
该 策略 实现 了 按照 线性 轮 询 的 方式 依次 选择 每 个 服务 实例 的 功能 。 
它 的 具体 实现 如 下 ， 其 详细 结构 与 RandomRule 非 常 类 似 。 除 了 循环 条 
件 不 同 外 ， 就 是 从 可 用 列表 中 获取 所 谓 的 逻辑 不 同 。 从 循环 条 件 中 ， 我 
们 可 以 看 到 增加 了 一 个 count 计 数 变 量 ， 该 变量 会 在 每 次 循环 之 后 款 
加 ， 也 就 是 说 ， 如 果 一 直选 择 不 到 server 超 过 10 次 ， 那 么 就 会 结束 洽 
试 ， 并 打印 一 个 警告 信息 No available alive servers after 10 tries from load 
balancer:…。 而 线性 轮 询 的 实现 则 是 通过 AtomicInteger 
nextServerCyclicCounter 对 象 实现 ， 每 次 进行 实例 选择 时 通过 调用 
incrementAndGetModulo 函 数 实 现 递增 。 





public Server choose (ILoadBalancer lb, Object key) { 


Server server = null; 
in Counk = DO 
while (server == null && count++ < 10) { 
List<Server> reachableServers = lb.getReachableServers ();} 
List<Server> allServers = lb.getAllServers(); 
int upCount = reachableServers.size();} 
int serverCount = allServers.size(); 
if ((upCount == 0) || (serverCount == 0)) { 
log.warn("No up servers available from load balancer: " + lb); 
return null; 
} 
int nextServerIindex = incrementAndGetModulo (serverCount);} 
server = allServers.get (nextServerIindex); 
if (server == null) { 
Thread.yield(); 
continue; 
} 
if (server.isAlive() && (server.isReadyToServe())) { 
return (server); 
} 


server = null; 


if (Gount >= LO) 4 
log.warn("No available alive servers after 10 tries from load balancer: 
+ TY 


} 
return server; 


} 


RetryRule 

该 策略 实现 了 一 个 具备 重 试 机 制 的 实例 选择 功能 。 从 下 面 的 实现 中 
我 们 可 以 看 到 ， 在 其 内 部 还 定义 了 一 个 IRule 对 象 ， 默 认 使 用 了 
RoundRobinRule 实 例 。 而 在 choose 方 法 中 则 实现 了 对 内 部 定义 的 策略 进 
行 反 复 答 试 的 策略 ， 奋 期 间 能 够 选择 到 具体 的 服务 实例 就 返回 ， 奉 选择 
不 到 就 根据 设置 的 尝试 结束 时 间 为 闵 值 (maxRetryMillis 参 数 定义 的 值 
+choose 方 法 开始 执行 的 时 间 戳 ; ， 当 超过 该 立 值 后 就 返回 null。 

public class RetryRule extends AbstractLoadBalancerRule { 

IRule subRule=new RoundRobinRule (): 

long maxRetryMillis=500; 


public Server choose (ILoadBalancer lb,Object key) { 
long requestTime=System.currentTimeMillis (); 
long deadline=requestTime+maxRetryMillis; 


Server answer=null; 

answer=subRule.choose (key) ; 

if ( ( (answer==null) || (! answer.isAlive () ) ) 
&& (System.currentTimeMillis () <deadline) ) { 
InterruptTask task=new InterruptTask (deadline 
-System.currentTimeMillis () ) ; 

while (! Thread.interrupted () ) { 
answer=subRule.choose (key) ; 

if ( ( (answer==null) || (! answer.isAlive () ) ) 
&& (System.currentTimeMillis () < deadline) ) { 
Thread.yield (); 

} else { 

break: 

} 

} 

task.cancel () ; 

} 

if ( (answer==null) || (!answer.isAlive () ) ) { 
return null; 

} else { 

return answer; 

} 

} 

} 

WeightedResponseTimeRule 

该 策略 是 对 RoundRobinRule 的 扩展 ， 增 加 了 根据 实例 的 运行 情况 来 


计算 权重 ， 并 根据 权重 来 挑选 实例 ， 以 达到 更 优 的 分 配 效 果 ， 它 的 实现 
主要 有 三 个 核心 内 容 。 


定时 任务 
WeightedResponseTimeRule 策 略 在 初始 化 的 时 候 会 通过 


serverWeightTimer.schedule (new 
DynamicServerWeightTask () ,0,serverWeightTaskTimerInterval) 启动 一 


个 定时 任务 ， 用 来 为 每 个 服务 实例 计算 权重 ,该 任务 默认 30 秒 执行 一 


class DynamicServerWeightTask extends TimerTask { 
public void run () { 


ServerWeight serverWeight=new ServerWeight 〈) ; 

try { 

serverWeight.maintainWeights (); 

} catch (Throwablet) { 

logger.error ("Throwable caught while running 
DynamicServerWeightTask for"+name,t) ; 

} 

} 

} 

权重 计算 

在 源码 中 我 们 可 以 轻松 找到 用 于 存储 权重 的 对 象 List<Double> 
accumulatedWeights=new ArrayList<Double> () ， 该 List 中 每 个 权重 值 
人 

yy. CS 

维护 实例 权重 的 计算 过 程 通过 maintainWeights 函 数 实 现 ， 有 具体 如 下 
面 的 代码 所 示 : 

public void maintainWeights () { 

ILoadBalancer lb=getLoadBalancer (); 





try { 

logger.info ("Weight adjusting job started") ; 
AbstractLoadBalancer nlb= (AbstractLoadBalancer) lb; 
LoadBalancerStats stats=nlb.getLoadBalancerStats (); 


/计算 所 有 实例 的 平均 响应 时 间 的 总 和 : totalResponseTime 

double totalResponseTime=0; 

for (Server server : nlb.getAllServers () ) { 

// 如 果 服 务实 例 的 状态 快照 不 在 缓存 中 ， 那 么 这 里 会 进行 自动 加 载 
ServerStats ss=stats.getSingleServerStat (server) ; 
totalResponseTime+=ss.getResponseTimeAvg 〈) ; 


} 

/逐个 计算 每 个 实例 的 权重 : weightSoFar+totalResponseTime- 实 例 的 
平均 响应 时 间 

Double weightSoFar=0.0; 

List<Double> finalWeights=new ArrayList<Double> 〈) ; 

for (Server server : nlb.getAllServers () ) { 

ServerStats ss=stats.getSingleServerStat (Server ) ; 


double weight=totalResponseTime-ss.getResponseTimeAvg 〈) ; 

weightSoFar+=weight; 

finalWeights.add (weightSoFar) ; 

} 

setWeights (finalWeights) ; 

} catch (Throwable t) { 

logger.error ("Exception while dynamically calculating server 
weights",t) ; 

} finally { 

serverWeightAssignmentInProgress.set 〈false) ; 


} 


} 

该 函数 的 实现 主要 分 为 两 个 步骤 : 

e 根 据 LoadBalancerStats 中 记录 的 每 个 实例 的 统计 信息 ， 累 加 所 有 实 
例 的 平均 啊 应 时 间 ， 得 到 总 平均 啊 应 时 间 totalResponseTime， 该 值 会 用 
于 后 续 的 计算 。 

e 为 负载 均衡 器 中 维护 的 实例 清单 逐个 计算 权重 〈 从 第 一 个 开始 ) ， 
计算 规则 为 weightSoFar+totalResponseTime 一 实例 的 平均 响应 时 间 ， 其 
中 weightSoFar 初 始 化 为 零 ， 并 且 每 计算 好 一 个 权重 需要 累加 到 
weightSoFar 上 供 下 一 次 计算 使 用 。 

举 个 简单 的 例子 来 理解 这 个 计算 过 程 ， 假 设 有 4 个 实例 A、B、C、 
D， 它 们 的 平均 响应 时 间 为 10、40、80、100， 所 以 总 响应 时 间 是 
10+40+80+100=230， 每 个 实例 的 权重 为 总 啊 应 时 间 与 实例 自身 的 平均 
啊 应 时 间 的 甜 的 畦 积 所 得 ， 所 以 实例 A、B、C、D 的 权重 分 别 如 下 所 

e 实 例 A:230-10=220 

e 实 例 B:220+ (230-40) =410 

e 实 例 C:410+ (230-80) =560 

e 实 例 D:560+ (230-100) =690 

需要 注意 的 是 ， 这 里 的 权重 值 只 是 表示 了 各 实例 权重 区 间 的 上 限 ， 
并 非 某 个 实例 的 优先 级 ， 所 以 不 是 数值 越 大 被 选中 的 概率 就 越 大 。 那 么 
什么 是 权重 区 间 呢 ? 以 上 面 例 子 的 计算 结果 为 例 ， 它 实际 上 是 为 这 4 个 
实例 构建 了 4 个 不 同 的 区 间 ， 每 个 实例 的 区 间 下 限 是 上 一 个 实例 的 区 间 
上 限 ， 而 每 个 实例 的 区 间 上 限 则 是 我 们 上 面 计 算 并 存储 于 List 
accumulatedWeights 中 的 权重 值 ， 其 中 第 一 个 实例 的 下 限 默 认为 零 。 所 
以 ， 根 据 上 面 示例 的 权重 计算 结果 ， 我 们 可 以 得 到 每 个 实例 的 权重 区 
间 。 






































e 实 例 A:[0,220] 

e 实 例 B: (220,410] 

e 实 例 C: (410,560] 

e 实例 D: (560,690) 

不 难 发 现 ， 实 际 上 每 个 区 间 的 宽度 就 是 : 总 的 平均 响应 时 间 - 实 例 的 
平均 响应 时 间 ， 所 以 实例 的 平均 响应 时 间 越 短 、 权 重 区 间 的 宽度 越 大 ， 
而 权重 区 间 的 宽度 越 大 被 选中 的 概率 就 越 高 。 可 能 很 多 读者 会 问 ， 这 些 
区 间 边 界 的 开 闭 是 如 何 确 定 的 呢 ? 为 什么 不 那么 规则 ? 下 面 我 们 会 通过 
实例 选择 算法 的 解读 来 解释 。 

实例 选择 

WeightedResponseTimeRule 选 择 实例 的 实现 与 之 前 介绍 的 算法 结构 
类 似 ， 下 面 是 它 主体 的 算法 〈 省 略 了 循环 体 和 一 些 判 断 等 处 理 ) : 














public Server choose (ILoadBalancer lb, Object key) { 
List<Double> currentWeights = accumulatedWeights; 


List<Server> allList = lb.getAllServers(); 
int serverCount = allList.size(); 
if (serverCount == 0) 1 
return null; 
} 
int serverIindex = 0; 
// 获取 最 后 一 个 实例 的 权重 
double maxTotalWeight = currentWeights.size() == 0 ? 0 : currentWeights.get 
(currentWeights.size() - 1); 
if (maxTotalWeight < 0.001Q) { 
// 如 果 最 后 一 个 实例 的 权重 值 小 于 0.001， 则 采用 父 类 实现 的 线性 轮 询 的 策略 
server = Super.choose (getLoadBalancer(), key); 
if(server == null) 1{ 
return server; 
} 
} else { 
// 如 果 最 后 一 个 实例 的 权重 值 大 于 等 于 0.001， 就 产生 一 个 [0，maxTotalWeight) 的 随机 数 
double randomWeight = random.nextDouble() * maxTotalWeight; 
tnt T= Oa 
for (Double d : currentWeights) { 
// 遍历 维护 的 权重 清单 ， 若 权重 大 于 等 于 随机 得 到 的 数值 ， 就 选择 这 个 实例 
if (d >= randomWeight) { 
serverIndex = n; 
break; 
} else { 
卫 十 十 7 
} 
} 
server = allList.get (serverIndex); 
} 


return server; 


1 

从 源码 中 我 们 可 以 看 到 ， 选 择 实例 的 核心 过 程 就 两 步 : 

e 生 成 一 个 [0， 最 大 权重 值 ) 区 间 内 的 随机 数 。 

e 人 授 历 权 重 列表 ， 比 较 权重 值 与 随机 数 的 大 小 ， 如 果 权 重 值 大 于 等 于 
随机 数 ， 就 拿 当 前 权重 列表 的 索引 值 去 服务 实例 列表 中 获取 有 具体 的 实 
例 。 这 残 是 在 上 一 蔬 中 提 到 的 服务 实例 会 根据 权重 区 间 挑 选 的 原理 ， 而 
权重 区 间 边 界 的 开 闭 原则 根据 算法 ， 正 钊 每 个 区 间 为 《xy] 的 形式 ， 但 
是 第 一 个 实例 和 最 后 一 个 实例 为 什么 不 同 呢 ? 由 于 随机 数 的 最 小 取 值 可 
以 为 0， 所 以 第 一 个 实例 的 下 限 是 闭 区 间 ， 同 时 随机 数 的 最 大 值 取 不 到 
最 大 权重 值 ， 所 以 最 后 一 个 实例 的 上 限 是 开 区 间 。 











若 继 续 以 上 面 的 数据 为 例 进行 服务 实例 的 选择 ， 则 该 方法 会 从 
[0,690) 区 间 中 选 出 一 个 随机 数 ， 比 如 选 出 的 随机 数 为 230， 由 于 该 值 位 
于 第 二 个 区 间 ， 所 以 此 时 就 会 选择 实例 B 来 进行 请 求 。 

ClientConfigEnabledRoundRobinRule 

该 策略 较为 特殊 ， 我 们 一 般 不 直接 使 用 它 。 因 为 它 本 号 并 没有 实现 
什么 特殊 的 处 理 逻 辑 ， 正 如 下 面 的 源码 所 示 ， 在 它 的 内 部 定义 了 一 个 
RoundRobinRule 策略 ， 而 choose 函 数 的 实现 也 正 是 使 用 了 
RoundRobinRule 的 线性 轮 询 机 制 ， 所 以 它 实 现 的 功能 实际 上 与 
RoundRobinRule 相 同 ， 那 么 定义 它 有 什么 特殊 的 用 处 呢 ? 

虽然 我 们 不 会 直接 使 用 该 策略 ， 但 是 通过 继承 该 策略 ， 默 认 的 
choose 驶 实现 了 线性 轮 询 机 制 ， 在 子 类 中 做 一 些 高 级 策略 时 通常 有 可 能 
会 存在 一 些 无 法 实施 的 情况 ， 那 么 就 可 以 用 父 类 的 实现 作为 备 选 。 在 后 
文中 我 们 将 继续 介绍 的 高 级 策略 均 是 基于 
ClientConfigEnabledRoundRobinRule 的 扩展 。 

public Class ClientConfigEnabledRoundRobinRule extends 
AbstractLoadBalancerRule { 

RoundRobinRule roundRobinRule=new RoundRobinRule (); 


(DOverride 

public Server choose (Object key) { 

if (roundRobinRule !=null) { 

return roundRobinRule.choose (key) ; 

} else { 

throw new lllegalArgumentException ( 

"This class has not been initialized with the RoundRobinRule class") ; 

} 

} 

} 

BestAvailableRule 

该 策略 继承 自 ClientConfigEnabledRoundRobinRule， 在 实现 中 它 注 入 
了 负载 均衡 器 的 统计 对 象 LoadBalancerStats， 同 时 在 具体 的 choose 算法 
中 利用 LoadBalancerStats 保 存 的 实例 统计 信息 来 选择 满足 要 求 的 实例 。 
从 如 下 源码 中 我 们 可 以 看 到 ， 它 通过 遍历 负载 均衡 器 中 维护 的 所 有 服务 
实例 ， 会 过 滤 挥 故障 的 实例 ， 并 找 出 并 发 请 求 数 最 小 的 一 个 ， 所 以 该 集 
略 的 特性 是 可 选 出 最 空 亲 的 实例 。 


Public Server choose (Object key) 1{ 
if (loadBalancerStats == null) { 
return super.choose (key)}); 
} 
List<Server> serverList = getLoadBalancer () .getAllServers (); 
int minimalConcurrentConnections = Integer.MAX VALUE; 
long currentTime = System.currentTimeMil]lis(); 
Server chosen = null; 
for (Server server: serverList) | 
ServerStats serverStats = loadBalancerStats.getSingleServerStat (server); 
if (!serverStats.isCircuitBreakerTripped(currentTime)) { 
int concurrentConnections = serverStats.getActiveRequestsCount (currentTime); 
if (concurrentConnections < minimalConcurrentConnections) f{ 
minimalConcurrentConnections = concurrentConnections; 
chosen = server; 


} 
} 
if (chosen == null) { 

return super.choose (key); 
} else { 

return chosen; 


} 


) 

同时 ， 由 于 该 算法 的 核心 依据 是 统计 对 象 loadBalancerStats， 当 其 为 
空 的 时 候 ， 该 策略 是 无 法 执行 的 。 所 以 从 源码 中 我 们 可 以 看 到 ， 当 
loadBalancerStats ”为 空 的 时 候 ， 它 会 采用 父 类 的 线性 轮 询 策略 ， 正 如 我 
们 在 介绍 ” ClientConfigEnabledRoundRobinRule 时 那样 ， 它 的 子 类 在 无 法 
满足 实现 高 级 策略 的 时 候 ， 可 以 使 用 线性 轮 询 策略 的 特性 。 后 面 将 要 介 
绍 的 策略 因为 也 都 继承 自 ClientConfigEnabledRoundRobinRule， 所 以 它 
们 都 会 具有 这 样 的 特性 。 

PredicateBasedRule 

这 是 一 个 抽象 策略 ， 它 也 继承 了 
ClientConfigEnabledRoundRobinRule， 从 其 命名 中 可 以 猜 出 这 是 一 个 基 
于 Predicate 实现 的 策略 ，Predicate 是 Google Guava Collection 工 具 对 集 
合 进 行 过 滤 的 条 件 接口 。 

如 下 面 的 源码 所 示 ， 它 定义 了 一 个 抽象 函数 getPredicate 来 获取 
AbstractServerPredicate 对 象 的 实现 ， 而 在 choose 函 数 中 ， 通 过 
AbstractServerPredicate 的 chooseRoundRobinAfterFiltering 函 数 来 选 出 具体 
的 服务 实例 。 从 该 函数 的 命名 我 们 也 大 致 能 猜 出 它 的 基础 逻辑 ， 先 通过 
子 类 中 实现 的 Predicate 逻辑 来 过 滤 一 部 分 服务 实例 ， 然 后 再 以 线性 轮 
询 的 方式 从 过 滤 后 的 实例 清单 中 选 出 一 个 。 


public abstract Class PredicateBasedRule extends 





ClientConfigEnabledRoundRobinRule { 
public abstract AbstractServerPredicate getPredicate () ; 
(DOverride 
public Server choose (Object key) { 
ILoadBalancer lb=getLoadBalancer (); 
Optional<Server> 
server=getPredicate () .chooseRoundRobinAfterFiltering 
(lb.getAllServers () ,key) ; 
if (server.isPresent () ) { 
return server.get (); 
} else { 
return null; 
} 
} 


} 

通过 下 面 AbstractServerPredicate 的 源码 片段 ， 可 以 证 实 我 们 上 面 所 
做 的 猜测 。 在 上 面 choose 函 数 中 调用 的 chooseRoundRobinAfterFiltering 
方法 先 通过 内 部 定义 的 ”getEligibleServers ”函数 来 获取 备 选 的 实例 清单 

《实现 了 过 滤 ) ， 如 果 返 回 的 清单 为 空 ， 则 用 Optionalabsent 〈) 来 表 

示 不 存在 ， 反 之 则 以 线性 轮 询 的 方式 从 备 选 清单 中 获取 一 个 实例 。 

public abstract Class Abstract9erverPredicate implements 
Predicate<PredicateKey> { 


public Optional<Server> 
chooseRoundRobinAfterFiltering (List<Server> servers,Object 
loadBalancerKey) { 

List<Server> eligible=getEligibleServers (servers,loadBalancerKey) ; 

if (eligible.size () ==0) { 

return Optional.absent (); 

} 

return Optional.of (eligible.get (nextIndex.getAndIncrement () % 
eligible. 

size () ) ) ; 

} 

public List<Server> getEligibleServers (List<Server> servers,Object 
loadBalancerKey) { 

if (loadBalancerKey==null) { 


return 
ImmutableList.copyOf 〈Iterables.filter (servers,this.getServerOnlyPredicate 
} else { 
List<Server> results=Lists.newArrayList () ; 
for (Server server: servers) { 
if (this.apply (new PredicateKey (loadBalancerKey,server) ) ) { 
results.add (server) ; 
} 
} 
return results; 
} 
} 


} 

在 了 解 了 整体 逻辑 之 后 ， 我 们 来 详细 看 看 实现 过 小 功能 的 
getEligibleServers 函 数 。 从 源码 上 看 ， 它 的 实现 结构 简 蛙 清晰 ， 通 过 亿 
历 服务 清单 ， 使 用 this.apply 方 法 来 判断 实例 是 否 需 要 保留 ， 如 果 是 就 添 
加 到 结果 列表 中 。 

可 能 到 这 里 ， 不 熟悉 Google Guava Collections 集 合 工 具 的 读者 会 感到 
困惑 ， 这 个 apply 在 AbstractServerPredicate 中 找 不 到 它 的 定义 ， 那 么 它 是 
如 何 实 现 过 滤 的 呢 ? 实际 上 ，AbstractServerPredicate 实现 了 
com.google.common.base.Predicate 接 口 ， 而 apply 方 法 是 该 接口 中 的 定 
义 ， 主 要 用 来 实现 过 小 条 件 的 判断 逻辑 ， 它 输入 的 参数 则 是 过 小 条 件 需 
要 用 到 的 一 些 信息 (比如 源码 中 的 new 
PredicateKey (loadBalancerKey,server) ) ， 它 传 入 了 关于 实例 的 统计 信 
恩 和 负载 均衡 器 的 选择 算法 传递 过 来 的 key)〉。 既 然 在 
AbstractServerPredicate 中 我 们 未 能 找到 apply 的 实现 ， 所 以 这 里 的 
chooseRoundRobinAfterFiltering 函 数 只 是 定义 了 一 个 模板 策略 :“ 先 过 滤 
清单 ， 再 轮 询 选 择 ”。 对 于 如 何 过 滤 ， 需 要 我 们 在 AbstractServerPredicate 
的 子 类 中 实现 apply 方 法 来 确定 具体 的 过 滤 策 略 。 

后 面 我 们 将 要 介绍 的 两 个 策略 就 是 基于 此 抽象 策略 实现 ， 只 是 它们 
使 用 了 不 同 的 Predicate 实 现 来 完成 过 滤 逻 辑 以 达到 不 同 的 实例 选择 效 
果 。 

Google Guava Collections 是 一 个 对 Java Collections Framework 增 强 和 
扩展 的 开源 项 目 。 虽 然 Java Collections Framework 己 经 能 够 满足 我 们 大 
多 数 情况 下 使 用 集合 的 要 求 ， 但 是 当 遇 到 一 些 特殊 的 情况 时 我 们 的 代码 
会 比较 元 长 且 容 易 出 错 。Guava _ Collections 可 以 帮助 我 们 让 集合 操作 代 
码 更 为 简短 精练 并 大 大 增强 代码 的 可 读 性 。 











AvailabilityFilteringRule 

该 策略 继承 自 上 面 介绍 的 抽象 策略 PredicateBasedRule， 所 以 它 也 继 
承 了 “ 先 过 滤 清 单 ， 再 轮 询 选 择 ” 的 基本 处 理 逻 辑 ， 其 中 过 滤 条 件 使 用 了 
AvailabilityPredicate: 

public class AvailabilityPredicate extends AbstractServerPredicate { 


public boolean apply (@Nullable PredicateKey input) { 

LoadBalancerStats stats=getLBStats (); 

if (stats==null) { 

return true; 

} 

return ! 
shouldSkipServer (stats.getSingleServerStat (input.getServer () ) ) ; 

} 

private boolean shouldSkipServer (ServerStats stats) { 

if ( (CIRCUIT BREAKER FILTERING.get () && 
stats.isCircuitBreakerTripped () ) 

| stats.getActiveRequestsCount () 
>=activeConnectionsLimit.get () ) { 

return true; 

} 

return false; 


} 


} 

从 上 述 源 码 中 ， 我 们 可 以 知道 它 的 主要 过 小 逻辑 位 于 
shouldSkipServer 方 法 中 ， 它 主要 判断 服务 实例 的 两 项 内 容 : 

e 是 否 故 障 ， 即 断路 器 是 否 生效 已 断 开 。 

e 实 例 的 并 发 请 求 数 大 于 国 值 ， 默 认 值 为 232 -1， 该 配置 可 通过 参数 
<cClientName>.<nameSpace>.ActiveConnectionsLimit 来 修改 。 

这 两 项 内 容 中 只 要 有 一 个 满足 apply 就 返回 false( 代 表 该 节点 可 能 
存在 故障 或 负载 过 高 ) ， 都 不 满足 驶 返回 true。 

在 该 策略 中 ， 除 了 实现 了 上 面 的 过 滤 方 法 之 外 ， 对 于 choose 的 策略 
也 做 了 一 些 改 进 优化 ， 所 以 父 类 的 实现 对 于 它 来 说 只 是 一 个 备用 选项 ， 
其 具体 实现 如 下 所 示 : 

public Server choose (Object key) { 

int count=0; 

Server server=roundRobinRule.choose (key) ; 








while (countt++<=10) { 

if (predicate.apply (new PredicateKey (server) ) ) { 
return server; 

} 

server=roundRobinRule.choose (key) ; 

} 


return super.choose (key) ; 


} 

可 以 看 到 ， 它 并 没有 像 在 父 类 中 那样 ， 先 裔 历 所 有 的 节点 进行 过 
滤 ， 然 后 在 过 滤 后 的 集合 中 选择 实例 。 而 是 先 以 线性 的 方式 选择 一 个 实 
例 ， 接 着 用 过 滤 条 件 来 判断 该 实例 是 否 满足 要 求 ， 若 满足 就 直接 使 用 该 
实例 ， 知 不 满足 要 求 束 再 选择 下 一 个 实例 ， 并 检查 是 人 否 满 足 要 求 ， 如 此 
循环 进行 ， 当 这 个 过 程 重复 了 10 次 还 是 没有 找到 符合 要 求 的 实例 ， 束 采 
用 父 类 的 实现 方案 。 

简单 地 说 ， 该 策略 通过 线性 抽样 的 方式 直接 尝试 寻找 可 用 日 较 空 亲 
的 实例 来 使 用 ， 优 化 了 父 类 每 次 都 要 遍历 所 有 实例 的 开销 。 

ZoneAvoidanceRule 

该 策略 我 们 在 介绍 负载 均衡 器 ZoneAwareLoadBalancer 时 已 经 提 到 
过 ， 它 也 是 PredicateBasedRule 的 具体 实现 类 。 在 之 前 的 介绍 中 主要 针对 
ZoneAvoidanceRule 中 用 于 选择 Zone 区 域 策 略 的 一 些 静态 函数 ， 比 如 
createSnapshot、getAvailableZones。 在 这 里 我 们 将 详细 看 看 
ZoneAvoidanceRule 作为 服务 实例 过 小 条 件 的 实现 原理 。 从 下 面 
ZoneAvoidanceRule 的 源码 片段 中 可 以 看 到 ， 它 使 用 了 
CompositePredicate 来 进行 服务 实例 清单 的 过 滤 。 这 是 一 个 组 合 过 滤 条 
件 ， 在 其 构造 函数 中 ， 它 以 ZoneAvoidancePredicate 为 主 过 滤 条 件 ， 
AvailabilityPredicate 为 次 过 滤 条 件 初 始 化 了 组 合 过 滤 条 件 的 实例 。 

public class ZoneAvoidanceRule extends PredicateBasedRule { 











private CompositePredicate compositePredicate; 
public ZoneAvoidanceRule () { 


super (); 

ZoneAvoidancePredicate zonePredicate=new 
ZoneAvoidancePredicate (this) ; 

AvailabilityPredicate availabilityPredicate=new 


AvailabilityPredicate (this) ; 
compositePredicate=createCompositePredicate (zonePredicate, 
availabilityPredicate ) ; 


} 

} 

ZoneAvoidanceRule 在 实现 的 时 候 并 没有 像 AvailabilityFilteringRule 那 
样 重 写 choose 函 数 来 优化 ， 所 以 它 完 全 遵循 了 父 类 的 过 滤 主 逻辑 :“ 先 
过 滤 清 单 ， 再 轮 询 选择 ”。 其 中 过 滤 清 单 的 条 件 就 是 我 们 上 面 提 到 的 以 
ZoneAvoidancePredicate 为 主 过 才 滤 条 件 、AvailabilityPredicate 为 次 过 滤 条 
件 的 组 合 过 滤 条 件 ”CompositePredicate。 从 CompositePredicate 的 源码 片 
段 中 ， 我 们 可 以 看 到 它 定义 了 一 个 主 过 滤 条 件 。” AbstractServerPredicate 
delegate 以 及 一 组 次 过 滤 条 件 列表 List fallbacks， 所 以 它 的 次 过 滤 列 表 


是 可 以 拥有 多 个 的 ， 并 且 由 于 它 采 用 了 List 存 储 所 以 次 过 滤 条 件 是 按 顺 
序 执行 的 。 


public class CompositePredicate extends AbstractServerPredicate { 





private AbstractServerPredicate delegate; 
private List<AbstractServerPredicate> fallbacks = Lists.newArrayList(); 


private int minimalFilteredServers = 1; 
private float minimalFilteredPercentage = 0; 


@Override 


public List<Server> getEligibleServers (List<Server> servers, Object 
loadBalancerKey) { 


List<Server> result = super.getEligibleServers (servers, loadBalancerKey); 
Iterator<AbstractServerPredicate> i = fallbacks.iterator (); 


while (!(result.size() >= minimalFilteredServers && result.size() > (int) 
(servers.size() * minimalFilteredPercentage)) 


&& i.hasNext()) { 
AbstractServerPredicate predicate = i.next(); 
result = predicate.getEligibleServers(servers, loadBalancerKey); 
} 


return result; 


本 在 获取 过 才 滤 结果 的 实现 函数 getEligibleServers 中 ， 它 的 处 理 逻 辑 如 下 
不 。 

e 使 用 主 过 滤 条 件 对 所 有 实例 过 滤 并 返回 过 滤 后 的 实例 清单 。 
0 过 滤 条 件 列表 中 的 过 滤 条 件 对 主 过 滤 条 件 的 结果 进行 过 
滤 。 

e 每 次 过 滤 之 后 (包括 主 过 滤 条 件 和 次 过 滤 条 件 ) ， 都 需要 判断 下 面 
两 个 条 件 ， 只 要 有 一 个 符合 就 不 再 进行 过 滤 ， 将 当前 结果 返回 供 线性 轮 
询 算法 选择 : 








四 过 滤 后 的 实例 总 数 >= 最 小 过 滤 实 例 数 CminimalFilteredServers， 默 
认为 1) 。 

加 过 小 后 的 实例 比例 > 最 小 过 小 百 分 比 (minimalFilteredPercentage， 
默认 为 0) 。 


MA) 


通过 上 一 节 对 Spring Cloud Ribbon 的 源码 分 析 ， 相 信 读 者 对 于 Ribbon 
的 几 个 重要 接口 都 已 经 有 所 了 了解。 下面 ， 我 们 将 详细 介绍 Ribbon 在 使 用 
时 的 各 种 配置 方式 。 


目 动 化 配置 


由 于 Ribbon 中 定义 的 每 一 个 接口 都 有 多 种 不 同 的 策略 实现 ， 同 时 这 
些 接口 之 间 又 有 一 定 的 依赖 关系 ， 这 使 得 第 一 次 使 用 Ribbon 的 开发 者 很 
难 上 手 ， 不 知道 如 何 选 择 具体 的 实现 策略 以 及 如 何 组 织 它们 的 关系 。 
Spring Cloud Ribbon 中 的 自动 化 配置 恰恰 能 够 解决 这 样 的 痛 点 ， 在 引入 
Spring Cloud Ribbon 的 依赖 之 后 ， 就 能 够 自动 化 构建 下 面 这 些 接口 的 实 
现 。 








eIClientConfig:Ribbon 的 客户 端 配置 ， 默 认 采 用 
com.netflix.client.config.DefaultClientConfigImpl 实 现 。 
eIRule:Ribbon 的 负载 均衡 策略 ， 默 认 采 用 


com.netflix.loadbalancer.ZoneAvoidanceRule 实 现 ， 该 策略 能 够 在 多 区 域 
环境 下 选 出 最 佳 区 域 的 实例 进行 访问 。 

eIPing:Ribbon 的 实例 检查 策略 ， 默 认 采 用 
com.netflix.loadbalancer.NoOpPing 实 现 ， 该 检查 策略 是 一 个 特殊 的 实 
现 ， 实 际 上 它 并 不 会 检查 实例 是 否 可 用 ， 而 是 始终 返回 ttue， 默 认 认为 
所 有 服务 实例 都 是 可 用 的 。 

eServerList<Server>: 服务 实例 清单 的 维护 机 制 ， 默 认 采 用 
com.netflix.loadbalancer.ConfigurationBasedServerList 实 现 。 

eServerListFilter<Server>: 服务 实例 清单 过 滤 机 制 ， 默 认 采 用 
org.Springframework.cloud.netflix.ribbon.ZonePreferenceServerLis tFilter 实 
现 ， 该 策略 能 够 优先 过 滤 出 与 请 求 调用 方 处 于 同 区 域 的 服务 实例 。 

eILoadBalancer: 负载 均衡 器 ， 默 认 采 用 
com.netflix.loadbalancer.ZoneAwareLoadBalancer 实 现 ， 它 具备 了 区 域 感 











上 面 这 些 自动 化 配置 内 容 仅 在 没有 引入 Spring Cloud Eureka 等 服务 治 
理 框架 时 如 此 ， 在 同时 引入 Eureka 和 Ribbon 依 赖 时 ， 自 动 化 配置 会 有 一 
些 不 同 ， 后 续 我 们 会 做 详细 的 介绍 。 

通过 上 自动 化 配置 的 实现 ， 我 们 可 以 轻松 地 实现 客户 端 负 载 均 衡 。 同 


时 ， 针 对 一 些 个 性 化 需求 ， 我 们 也 可 以 方便 地 蔡 换 上 面 的 这 些 默认 实 
现 。 只 需 在 Spring Boot 应 用 中 创建 对 应 的 实现 实例 就 能 履 新 这 些 默 认 的 
配置 实现 。 比 如 下 面 的 配置 内 容 ， 由 于 创建 了 PingUnl 实 例 ， 所 以 默认 
的 NoOpPing 就 不 会 被 创建 。 

Q@Configuration 

public class MyRibbonConfiguration { 

Bean 

public IPing ribbonPing (IClientConfig config) { 

return new PingUrl () ; 


} 


} 

另外 ， 也 可 以 通过 使 用 @RibbonClient 注 解 来 实现 更 细 粒 度 的 客户 端 
配置 ， 比 如 下 面 的 代码 实现 了 为 hello-service 服 务 使 用 
HelloServiceConfiguration 中 的 配置 。 

@Configuration 

@RibbonClient (name="hello- 
service",configuration=HelloServiceConfiguration.class ) 

public class RibbonConfiguration { 


} 
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上 面 我 们 介绍 了 在 Brixton 版 本 中 对 RibbonClient 的 IPing、IRule 等 接 
口 实现 进 行 个 性 化 定制 的 方法 ， 主 要 通过 独立 创建 一 个 Configuration 类 
来 定义 IPing、IRule 等 接口 的 具体 实现 Bean， 然 后 在 创建 RibbonClient 时 
指定 要 使 用 的 具体 Configuration 类 来 覆盖 自动 化 配置 的 默认 实现 。 虽 然 
这 种 方式 已 经 能 够 实现 个 性 化 的 定义 ， 但 是 当 有 大 量 这 类 配置 的 时 候 ， 
对 于 各 个 RibbonClient 的 指定 配置 信息 都 将 分 散在 这 些 配 置 类 的 注解 定 
义 中 ， 这 使 得 管理 和 修改 都 变 得 非常 不 方便 。 所 以 ， 在 Camden 版 本 
中 ，Spring Cloud Ribbon 对 RibbonClient 定义 个 性 化 配置 的 方法 做 了 进 
一 步 优 化 。 可 以 直接 通过 <clientName>.ribbon.<key>=<value> 的 形式 进 
行 配置 。 比 如 我 们 要 实现 与 上 面 例子 一 样 的 配置 (将 hello-service 服 务 客 
户 端的 IPing 接 口 实现 蔡 换 为 PingUrl) ， 只 需 在 application.properties 配 置 
中 增加 下 面 的 内 容 即 可 : 

hello- 
service.ribbon.NFLoadBalancerPingClassName=com.netflix.loadbalancer.Pin 

其 中 hello-service 为 服务 名 ，NFLoadBalancerPingClassName 参数 用 














来 指定 具体 的 IPing 接口 实现 类 。 在 Camden 版 本 中 ，Spring Cloud 
Ribbon 新 增 了 一 个 
org.springframework.cloud.netflix.ribbon.PropertiesFactory 类 来 动态 地 为 
RibbonClient 创 建 这 些 接口 实现 。 

public class PropertiesFactory { 

(OAutowired 

private Environment environment; 

private Map<Class, String> classToProperty=new Hash Map<> (); 

public PropertiesFactory () { 

classToProperty.put (ILoadBalancer.class,"NFLoadBalancerClassName" 

classToProperty.put (IPing.class,"NFLoadBalancerPingClassName") ; 

classToProperty.put (IRule.class,"NFLoadBalancerRuleClassName") ; 

classToProperty.put (ServerList.class,"NIWSServerListClassName") ; 

classToProperty.put (ServerListFilter.class,"NIWSServerListFilterClassN 

} 

public boolean isSet (Class clazz,String name) { 

return StringUtils.hasText (getClassName (clazz,name) ) ; 

} 

public String getClassName (Class clazz,String name) { 

if (this.classToProperty.containsKey (clazz) ) { 

String classNameProperty=this.classToProperty.get (clazz) ; 

String 
className=environment.getProperty (name+"."+NAMESPACE+"."+classN. 

return className; 

} 

return null: 

} 

@SuppressWarnings ("unchecked") 

public <C> C get (Class<C> clazz,IClientConfig config,String name) { 

String className=getClassName (clazz,name) ; 

if (StringUtils.hasText (className) ) { 

try { 

Class<? > toInstantiate=Class.forName (className) ; 

return (C) instantiateWithConfig (toInstantiate,config) ; 

} catch (ClassNotFoundException e) { 

throw new IllegalArgumentException ("Unknown dlass to 
load"+className+" for class "+clazz+" named "+name) ; 


} 
} 
return null; 


} 


} 
从 上 述 源码 定义 中 可 以 看 到 , 除了 NFLoadBalancerPingClassName 
参数 之 外 ， 还 提供 了 其 他 几 个 接口 的 动态 配置 实现 ， 具 体 如 下 所 述 。 
eNFLoadBalancerClassName: 配置 ILoadBalancer 接 口 的 实现 。 
eNFLoadBalancerPingClassName: 配置 IPing 接 口 的 实现 。 
eNFLoadBalancerRuleClassName: 配置 IRule 接 口 的 实现 。 
eNIWSServerListClassName: 配置 ServerList 接 口 的 实现 。 
eNIWSServerListFilterClassName: 配置 ServerListFilter 接 口 的 实现 。 
所 以 ， 在 Camden 版 本 中 我 们 可 以 通过 配置 的 方式 ， 更 加 方便 地 为 
RibbonClient 指 定 ILoadBalancer、IPing、IRule、ServerList 和 
ServerListFilter 的 定制 化 实现 。 
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于 Ribbon 的 参数 配置 通常 有 两 种 方式 : 全 局 配置 以 及 指定 客户 端 
配置 。 
e 全 局 配置 的 方式 很 简单 ， 只 需 使 用 ribbon.<key>=<value> 格 式 进行 
配置 即 可 。 

其 中 ，<key> 代 表 了 Ribbon 客户 端 配置 的 参数 名 ，<value> 则 代表 了 
对 应 参数 的 值 。 比 如 ， 我 们 可 以 像 下 面 这 样 全 局 配置 Ribbon 创 建 连接 的 
超时 时 间 : 

ribbon.ConnectTimeout=250 

全 局 配置 可 以 作为 默认 值 进行 设置 ， 当 指定 客户 端 配置 了 相应 key 的 
值 时 ， 将 履 盖 全 局 配置 的 内 容 。 

e 指 定 客户 端的 配置 方式 采用 <client>.ribbon.<key>=<value> 的 格式 进 
行 配置 。 其 中 ，<key> 和 <value> 的 含义 同 全 局 配置 相同 ， 而 <client> 代 
表 了 客户 端的 名 称 ， 如 上 文中 我 们 在 @RibbonClient 中 指定 的 名 称 ， 也 
可 以 将 它 理 解 为 是 一 个 服务 名 。 为 了 方便 理解 这 种 配置 方式 ， 我 们 举 一 
个 具体 的 例子 : 假设 ， 有 一 个 服务 消费 者 通过 RestTemplate 来 访问 hello- 
service 服 务 的 /hello 接 口 ， 这 时 我 们 会 这 样 调用 
restTemplate.getForEntity ("http://helloservice/hello",String.class ) .getBody 
如 果 没 有 服务 治理 框架 的 帮助 ， 我 们 需要 为 该 客户 痢 指 定 具 体 的 实例 清 
单 ， 可 以 指定 服务 名 来 做 详细 的 配置 ， 具 体 如 下 : 








hello- 
service.ribbon.listOfServers=localhost:8001,localhost:8002,localhost:8003 

对 于 Ribbon 参 数 的 key 以 及 value 类 型 的 定义 ， 可 以 通过 查看 
com.netflix.client.config.CommonClientConfigKey 类 获得 更 为 详细 的 配置 
内 容 ， 在 本 书 中 不 进行 详细 介绍 。 


与 Eureka 结 合 


当 在 Spring Cloud 的 应 用 中 同时 引入 Spring Cloud Ribbon 和 Spring 
Cloud ”Eureka 依 赖 时 ， 会 触发 Eureka 中 实现 的 对 Ribbon 的 自动 化 配置 。 
这 时 ServerList 的 维护 机 制 实 现 将 被 
com.netflix.niws.loadbalancer.DiscoveryEnabledNIWSServerList 的 实例 所 
履 新 ， 该 实现 会 将 服务 清单 列表 交 给 Eureka 的 服务 治理 机 制 来 进行 维 
护 ; IPing 的 实现 将 被 ”com.netflix.niws.loadbalancer.NIWSDiscoveryPing 
的 实例 所 履 产 ， 该 实现 也 将 实例 检查 的 任务 交 给 了 服务 治理 框架 来 进行 
维护 。 默 认 情 况 下 ， 用 于 获取 实例 请 求 的 ServerList 接 口 实现 将 采用 
Spring Cloud Eureka 中 封装 的 
org.springframework.cloud.netflix.ribbon.eureka.DomainExtractingServerL ist 
其 目的 是 为 了 让 实例 维护 策略 更 加 通用 ， 所 以 将 使 用 物理 元 数据 来 进行 
负载 均衡 ， 而 不 是 使 用 原生 的 AWS AMI 元 数据 。 

在 与 Spring Cloud Eureka 结 合 使 用 的 时 候 ， 我 们 的 配置 将 会 变 得 更 加 
简单 。 不 再 需要 通过 类 似 hello-service.ribbon.listOfServers 的 参数 来 指定 
具体 的 服务 实例 清单 ， 因 为 Eureka 将 会 为 我 们 维护 所 有 服务 的 实例 清 
单 。 而 对 于 Ribbon 的 参数 配置 ， 我 们 依然 可 以 采用 之 前 的 两 种 配置 方式 
来 实现 ， 而 指定 客户 问 的 配置 方式 可 以 直接 使 用 Eureka 中 的 服务 名 作为 
<client> 来 完成 针对 各 个 微服 务 的 个 性 化 配置 。 

此 外 ， 由 于 Spring Cloud Ribbon 默 认 实 现 了 区 域 杀 和 策略 ， 所 以 ， 我 
们 可 以 通过 Eureka 实 例 的 元 数据 配置 来 实现 区 域 化 的 实例 配置 方案 。 比 
如 ， 可 以 将 处 于 不 同 机 房 的 实例 配置 成 不 同 的 区 域 值 ， 以 作为 跨 区 域 的 
容错 机 制 实 现 。 而 实现 的 方式 非常 简单 ， 只 需 在 服务 实例 的 元 数据 中 增 
加 zone 参 数 来 指定 自己 所 在 的 区 域 ， 比 如 : 

eureka.instance.metadataMap.zone=shanghai 

在 Spring Cloud Ribbon 与 Spring Cloud Eureka 结 合 的 工程 中 ， 我 们 也 
可 以 通过 参数 配置 的 方式 来 禁用 Eureka 对 Ribbon 服 务实 例 的 维护 实现 。 

只 需 在 配置 文件 中 加 入 如 下 参数 ， 这 时 我 们 对 于 服务 实例 的 维护 就 又 将 
回归 到 使 用 <client>.ribbon.listOfServers 参数 配置 的 方式 来 实现 了 。 


ribbon.eureka.enabled=false 
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由 于 Spring Cloud Eureka 实现 的 服务 治理 机 制 强调 了 CAP 原 理 中 的 
AP， 即 可 用 性 与 可 靠 性 ， 它 与 ZooKeeper 这 类 强调 CP 〈 一 致 性 、 可 靠 
性 ) 的 服务 治理 框架 最 大 的 区 别 就 是 ，Eureka 为 了 实现 更 高 的 服务 可 用 
性 ， 牺 牲 了 一 定 的 一 致 性 ， 在 极端 情况 下 它 宁 愿 接受 故障 实例 也 不 要 于 
掉 “ 健 康 ” 实 例 ， 比 如 ， 当 服务 注册 中 心 的 网 络 发 生 故 障 断 开 时 ， 由 于 所 
有 的 服务 实例 无 法 维持 续 约 心跳 ， 在 强调 AP 的 服务 治理 中 将 会 把 所 有 
服务 实例 都 剔除 掉 ， 而 Eureka 则 会 因为 超过 85% 的 实例 丢失 心跳 而 会 触 
发 保护 机 制 ， 注 册 中 心 将 会 保留 此 时 的 所 有 节点 ， 以 实现 服务 间 依 然 可 
以 进行 互相 调用 的 场景 ， 即 使 其 中 有 部 分 故障 和 点， 但 这 样 做 可 以 继续 
保障 大 多 数 的 服务 正常 消费 。 

由 于 Spring Cloud Eureka 在 可 用 性 与 一 至 性 上 的 取舍 ， 不 论 是 由 于 触 
发 了 保护 机 制 还 是 服务 剔除 的 延迟 ， 引 起 服务 调用 到 故障 实例 的 时 候 ， 
我 们 还 是 希望 能 够 增强 对 这 类 问题 的 容错 。 所 以 ， 我 们 在 实现 服务 调用 
的 时 候 通 常会 加 入 一 些 重 试 机 制 。 在 目前 我 们 使 用 的 Brixton 版 本 中 ， 对 
于 重 试 机 制 的 实现 需要 我 们 自己 来 扩展 完成 。 而 从 Camden SR2 版 本 开 
始 ，Spring Cloud 整 合 了 Spring Retry 来 增强 RestTemplate 的 重 试 能 力 ， 对 
于 开发 者 来 说 只 需 通 过 人 简单 的 配置 ， 原 来 那些 通过 RestTemplate 实现 的 
服务 访问 束 会 目 动 根据 配置 来 实现 重 试 策略 。 

以 我 们 之 前 对 hello-service 服 务 的 调用 为 例 ， 可 以 在 配置 文件 中 增加 
如 下 内 容 : 

spring.cloud.loadbalancer.retry.enabled=true 

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds 

hello-service.ribbon.ConnectTimeout=250 
hello-service.ribbon.ReadTimeout=1000 
hello-service.ribbon.OkToRetryOnAllOperations=true 
hello-service.ribbon.MaxAutoRetries NextServer=2 
hello-service.ribbon.MaxAutoRetries=1 

其 中 各 参数 的 配置 说 明 如 下 所 示 。 

espring.cloud.loadbalancer.retry.enabled: 该 参数 用 来 开启 重 试 机 制 ， 
它 默 认 是 关闭 的 。 这 里 需要 注意 ， 官 方 文档 中 的 配置 参数 少 了 enabled。 
该 参数 的 源码 定义 如 下 : 

@ConfigurationProperties ("spring.cloud.loadbalancer.retry") 

public class LoadBalancerRetryProperties { 

private boolean enabled=false; 

















} 

ehystrix.command.default.execution.isolation.thread.timeoutIn 
Milliseconds: 断路 堪 的 超时 时 间 需 要 大 于 Ribbon 的 超时 时 间 ， 不 然 不 
会 触发 重 试 。 

ehello-service.ribbon.ConnectTimeout: 请 求 连接 的 超时 时 间 。 

ehello-service.ribbon.ReadTimeout: 请 求 处 理 的 超时 时 间 。 

ehello-service.ribbon.OkToRetryOnAllOperations: 对 所 有 操作 请 求 都 
进行 重 试 。 

ehello-service.ribbon.MaxAutoRetriesNextServer: 切换 实例 的 重 试 次 
数 。 

ehello-service.ribbon.MaxAutoRetries: 对 当前 实例 的 重 试 次 数 。 

根据 如 上 配置 ， 当 访问 到 故障 请 求 的 时 候 ， 它 会 再 尝试 访问 一 次 当 
前 实例 〈 次 数 由 MaxAutoRetries 配 置 ) ， 如 果 不 行 ， 就 换 一 个 实例 进行 
访问 ， 如 果 还 是 不 行 ， 再 换 一 次 实例 访问 《更 换 次 数 由 
MaxAutoRetriesNextServer 配 置 ) ， 如 果 依 然 不 行 ， 返 回 失 败 信 息 。 





第 5 音 务 容错 保护 : Sprin 


Cloud Hystrix 


在 微服 务 架 构 中 ， 我 们 将 系统 拆 分 成 了 很 多 服务 单元 ， 各 单元 的 应 
用 间 通 过 服务 注册 与 订阅 的 方式 互相 依赖 。 由 于 每 个 单元 都 在 不 同 的 进 
程 中 运行 ， 依 赖 遂 过 远程 调用 的 方式 执行 ， 这 样 就 有 可 能 因为 网 络 原 因 
或 是 依赖 服务 自身 问题 出 现 调用 故障 或 延迟 ， 而 这 些 问题 会 直接 导致 调 
用 方 的 对 外 服务 也 出 现 延 人 运 ， 若 此 时 调用 方 的 请 求 不 断 增 加 ， 最 后 就 会 
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举 个 例子 ， 在 一 个 电 商 网 站 中 ， 我 们 可 能 会 将 系统 拆 分 成 用 户 、 订 
单 、 库 存 、 积 分 、 评 论 等 一 系列 服务 单元 。 用 户 创建 一 个 订单 的 时 候 ， 
客户 并 将 调用 订单 服务 的 创建 订单 接口 ， 此 时 创建 订单 接口 又 会 同 库存 
服务 来 请 求 出 贷 ( 判 断 是 否 有 由 够 库存 来 出 货 ) 。 此 时 知 库 存 服务 因 目 
身 处 理 罗 辑 等 原因 造成 啊 应 缓慢 ， 会 直接 导致 创建 订单 服务 的 线程 被 挂 
起 ， 以 等 竺 库存 申请 服务 的 啊 应 ， 在 漫长 的 等 待 之 后 用 户 会 因为 请 求 库 
存 失败 而 得 到 创建 订单 失败 的 结果 。 如 果 在 高 并 发 情况 之 下 ， 因 这 些 挂 
起 的 线程 在 等 待 库存 服务 的 啊 应 而 未 能 释放 ， 使 得 后 续 到 来 的 创建 订单 
请 求 被 阻塞 ， 最 终 导 致 订单 服务 也 不 可 用 。 

在 微服 务 架 构 中 ， 存 在 着 那么 多 的 服务 单元 ， 知 一 个 单元 出 现 故 
障 ， 束 很 容易 因 依 赖 关 系 而 引发 故障 的 营 延 ， 最 终 导 臻 整个 系统 的 次 
次， 这 样 的 架构 相 较 传统 架构 更 加 不 稳定 。 为 了 解决 这 样 的 问题 ， 产 生 
了 断路 器 等 一 系列 的 服务 保护 机 制 。 

断路 器 模式 源 于 Martin Fowler 的 Circuit Breaker 一 文 。“ 断 路 器 >” 本身 
是 一 种 开关 装置 ， 用 于 在 电路 上 保护 线路 过 载 ， 当 线路 中 有 电器 发 生 短 
路 时 , “断路 器 ?能够 及 时 切断 故障 电路 ， 防 止 发 生 过 载 、 发 热 甚 至 起 火 
等 严重 后 果 。 

在 分 布 式 架构 中 ， 断 路 器 模式 的 作用 也 是 类 似 的 ， 当 某 个 服务 单元 
发 生 故 障 〈 类 似 用 电器 发 生 短 路 ) 之 后 ， 通 过 断路 右 的 故障 监控 (类 似 
熔断 保险 丝 ) ， 辐 调用 方 返回 一 个 错误 啊 应 ， 而 不 是 长 时 间 的 等 待 。 这 
样 就 不 会 使 得 线程 因 调 用 故障 服务 被 长 时 间 占 用 不 释放 ， 避 人 免 了 故障 在 
分 布 式 系统 中 的 蔓延 。 

针对 上 述 问 题 ，Spring Cloud Hystrix 实 现 了 断路 器 、 线 程 隔离 等 一 系 
列 服务 保护 功能 。 它 也 是 基于 Netflix 的 开源 框架 Hystrix 实 现 的 ， 该 框架 



































的 目标 在 于 通过 控制 那些 访问 远程 系统 、 服 务 和 第 三 方 库 的 节点 ， 从 而 

对 延迟 和 故障 提供 更 强大 的 容错 能 力 。Hystrix 具 备 服务 降 级 、 服 务 熔 

上 晰 、 线 程 和 信号 隔离 、 请 求 缓存 、 请 求 合并 以 及 服务 监控 等 强大 功能 。 

接 下 来 ， 我 们 束 从 一 个 简单 示例 开始 对 Spring Cloud Hystrix 的 学 习 与 
用 。 
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在 开始 使 用 Spring Cloud Hystrix 实 现 断 路 器 之 前 ， 我 们 先 用 之 前 实现 
的 一 些 内 容 作 为 基础 ， 构 建 一 个 如 下 图 架构 所 示 的 服务 调用 关系 。 
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我 们 在 这 里 需要 启动 的 工程 有 如 下 一 些 。 

eeureka-server 工 程 ， 服务 注册 中 心 ， 端 口 为 1111。 

ehello-service 工 程 : HELLO-SERVICE 的 服务 单元 ， 两 个 实例 启动 端 
口 分 别 为 8081 和 8082。 

eribbon-consume 工 程 : 使 用 Ribbon 实 现 的 服务 消费 者 ， 端 口 为 
9000。 

在 未 加 入 断路 器 之 前 ， 关 闭 8081 的 实例 ， 发 送 GET 请 求 到 
http://localhost:9000/ribbon-consumer， 可 以 获得 下 面 的 输出 : 

| 

"timestamp": 1473992080343， 

"status": 500, 

"error": "Internal Server Error", 

"exception": 
"org.springframework.web.client.ResourceAccessException", 

"message": "lO error on GET request for \"http://HELLO- 


SERVICE/hello\":Connection refused: connect; nested exception is 
java.net.ConnectException: Connection refused: connect", 
"path": ribbon-consumer" 


} 

下 面 我 们 开始 引入 Spring Cloud Hystrix。 

e 在 ribbon-consumer 工程 的 pom.xml 的 dependency 节点 中 引入 
springcloud-starter-hystrix 依 赖 : 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-hystrix</artifactId> 

</dependency> 

e 在 ”ribbon-consumer 工程 的 主 类 ConsumerApplication 中 使 用 
@EnableCircuitBreaker 注 解 开 局 断 路 右 功 能 : 

EnableCircuitBreaker 

@EnableDiscoveryCljlient 

SpringBootApplication 

public class ConsumerApplication { 

Bean 

LoadBalanced 

RestTemplate restTemplate () { 

return new RestTemplate (); 

} 

public static void main (String[]args) { 

SpringApplication.run (ConsumerApplication.class,args) ; 


注意 : 这 里 还 可 以 使 用 Spring Cloud 应 用 中 的 
@SpringCloudApplication 注 解 来 修饰 应 用 主 类 ， 访 注解 的 具体 定义 如 下 
所 示 。 可 以 看 到 ， 该 注解 中 包含 了 上 述 我 们 所 引用 的 三 个 注解 ， 这 也 意 
味 着 一 个 Spring Cloud 标 准 应 用 应 包含 服务 发 现 以 及 断路 器 。 

@Target ({ElementType.TYPE}) 

@Retention (RetentionPolicy.RUNTIME) 

Documented 

QInherited 

SpringBootApplication 

人 EnableDiscoveryCljlient 

(EnableCircuitBreaker 





public COinterface SpringCloudApplication { 


e 改 造 服务 消费 方式 ， 新 增 HelloService 类 ， 注 入 RestTemplate 实 例 。 
然后 ， 将 在 ConsumerController 中 对 RestTemplate 的 使 用 迁移 到 
helloService 函 数 中 ， 最 后 ， 在 helloService 函 数 上 增加 @HystrixCommand 
注解 来 指定 回调 方法 : 

(9 Service 

public class HelloService { 

(OAutowired 

RestTemplate restTemplate; 

@HystrixCommand (fallbackMethod="helloFallback") 

public String helloService () { 

return restTemplate.getForEntity ("http:/HELLO-SERVICE/hello", 

String.class) .getBody (); 

} 

public String helloFallback () { 

return "error"; 

} 

} 

e 修 改 ConsumerController 类 ， 注 入 上 面 实现 的 HelloService 实例 ， 
并 在 helloConsumer 中 进行 调用 : 

(DRestController 

public class ConsumerController { 

(OAutowired 

HelloService helloService; 

@RequestMapping (value="/ribbon- 
consumer",method=RequestMethod.GET) 

public String helloConsumer () { 

return helloService.helloService () ; 


} 


} 

下 面 ， 我 们 来 验证 一 下 通过 断路 器 实现 的 服务 回调 逻辑 ， 重 新 局 动 
之 前 关闭 的 8081 端 口 的 Hello-Service， 确 保 此 时 服务 注册 中 心 、 两 个 
Hello-Service 以 及 RIBBONCONSUMER 均 已 启动 ， 访 问 
http://localhost:9000/ribbon-consumer 可 以 轮 询 两 个 HELLO-SERVICE 并 返 
回 一 些 文字 信息 。 此 时 我 们 继续 断 开 8081 的 HELLO-SERVICE， 然 后 访 
问 http:/Wlocalhost:9000ribbon-consumer， 当 轮 询 到 8081 服 务 端 时 ， 输 出 


内 容 为 error， 不 再 是 之 前 的 错误 内 容 ，Hystrix 的 服务 回调 生效 。 除 了 通 
过 断 开 具体 的 服务 实例 来 模拟 茶 个 点 无 法 访问 的 情况 之 外 ， 我 们 还 可 
以 模拟 一 下 服务 阻塞 〈 长 时 间 未 啊 应 ) 的 情况 。 我 们 对 HELLO- 
SERVICE 的 /hello 接 口 做 一 些 修 改 ， 有 具体 如 下 : 

@RequestMapping (value="/hello",method=RequestMethod.GET) 

public String hello () throws Exception { 

ServiceInstance instance=client.getLocalServiceInstance (); 

1/ 让 处 理 线 程 等 待 几 秒 钟 

int sleepTime=new Random () .nextInt (3000); 

logger.info ("sleepTime:"+sleepTime) ; 

Thread.sleep (sleepTime) ; 

logger.info ("/hello,host:"+instance.getHost () 
+",service id:"+instance.getServiceld () ) ; 

return "Hello World"; 


} 

通过 Thread.sleep 〈) 函数 可 让 /hello 接 口 的 处 理 线程 不 是 马上 返回 内 
容 ， 而 是 在 阻塞 几 秒 之 后 才 返 回 内 容 。 由 于 Hystrix 默 认 超时 时 间 为 2000 
坚 秒 ， 所 以 这 里 采用 了 0 至 3000 的 随机 数 以 让 处 理 过 程 有 一 定 概 京 友 生 
超时 来 触发 邮 路 费 。 为 了 更 精准 地 观察 电 路 旨 的 触 太 ， 在 消费 者 调用 函 
数 中 做 一 些 时 间 记 录 ， 具 体 如 下 : 

@HystrixCommand (fallbackMethod="helloFallback",commandKey="h 

public String hello () { 

long start=System.currentTimeMillis (); 


1/ 消费 服务 的 逻辑 


long end=System.currentTimeMillis (); 
logger.info ("Spend time : "+ (end-start) ) ; 
return result.toString (); 


} 

重新 启动 HELLO-SERVICE 和 RIBBON-CONSUMER 的 实例 ， 连 续 
访问 http://localhost:9000/ribbon-consumer 几 次 ， 我 们 可 以 观察 到 ， 当 
RIBBON-CONSUMER 的 控制 台中 输出 的 Spend time 大 于 2000 的 时 候 ， 就 
会 返回 error， 即 服务 消费 者 因 调 用 的 服务 超时 从 而 触发 熔断 请 求 ， 并 调 
用 回调 逻辑 返回 结果 。 


原理 分 析 


通过 上 面 的 快速 入 门 示例 ， 我 们 对 Hystrix 的 使 用 场景 和 使 用 方法 已 
经 有 了 一 个 基础 的 认识 。 接 下 来 我 们 通过 解读 Netflix Hystrix 官 方 的 流程 
图 来 详细 了 解 一 下 : 当 一 个 请 求 调用 了 相关 服务 依赖 之 后 Hystrix 是 如 
何 工 作 的 《〈 即 如 上 例 中 所 示 ， 当 访问 了 http:/localhost:9000mibbon- 
consumer 请 求 之 后 ， 在 RIBBON-CONSUMER 中 是 如 何 处 理 的 ) 。 


工 VS 不 号 
下 面 我 们 根据 图 中 标记 的 数字 顺序 来 解释 每 一 个 环节 的 详细 内 容 。 

















1. 创 建 HystrixCommand 或 HystrixObservableCommand 对 象 
首先 ， 构 建 一 个 HystrixCommand 或 是 HystrixObservableCommand 对 
象 ， 用 来 表示 对 依赖 服务 的 操作 请 求 ， 同 时 传递 所 有 需要 的 参数 。 从 其 





命名 中 我 们 就 能 知道 它 采 用 了 “命令 模式 ”来 实现 对 服务 调用 操作 的 封 
装 。 而 这 两 个 Command 对 象 分 别针 对 不 同 的 应 用 场景 。 
eHystrixCommand: 用 在 依赖 的 服务 返回 单个 操作 结果 的 时 候 。 
eHystrixObservableCommand: 用 在 依赖 的 服务 返回 多 个 操作 结果 的 
时 候 。 
命令 模式 ， 将 来 自 客户 端的 请 求 封装 成 一 个 对 象 ， 从 而 让 你 可 以 使 
用 不 同 的 请 求 对 客户 端 进行 参数 化 。 它 可 以 被 用 于 实现 “行为 请 求 
者 ”与 “行为 实现 者 ”的 解 厅 ， 以 便 使 两 者 可 以 适应 变化 。 下 面 的 示例 是 





对 命令 模式 的 简单 实现 : 
// 接 收 者 
public class Receiver { 
public void action () { 
// 真 正 的 业务 逻辑 
} 


} 

// 抽 象 命 令 

interface Command { 
void execute () : 


} 

/具体 命令 实现 

public class ConcreteCommand implements Command { 
private Receiver receiver; 

public ConcreteCommand (Receiver receiver) { 
this.receiver=receiver; 

} 

public void execute () { 

this.receiver.action (); 


} 
} 
/客户 端 调用 者 


public class Invoker { 

private Command command; 

public void setCommand (Command command) { 
this.command=command; 

} 

public void action () { 

this.command.execute () ; 

} 

} 

public class Client { 

public static void main (String[]args) { 

Receiver receiver=new Receiver () ; 

Command command=new ConcreteCommand (receiver) ; 
Invoker invoker=new Invoker () ; 
invoker.setCommand (command ) ; 


invoker.action () ; /客户 端 通过 调用 者 来 执行 命令 
} 


} 

从 代码 中 ， 我 们 可 以 看 到 这 样 几 个 对 象 。 

eReceiver: 接收 者 ， 它 知道 如 何 处 理 具 体 的 业务 逻辑 。 

eCommand: 抽象 命令 ， 它 定义 了 一 个 命令 对 象 应 具备 的 一 系列 命 
令 操 作 ， 比 如 execute () 、undo () 、redo() 等 。 当 命令 操作 被 调用 
的 时 候 就 会 触发 接收 者 去 做 具体 命令 对 应 的 业务 逻辑 。 

eConcreteCommand: 县 体 的 命令 实现 ， 在 这 里 它 绑 定 了 命令 操作 与 
接收 者 之 间 的 关系 ，execute 〈) 命令 的 实现 委托 给 了 Receiver 的 
action () 函数 。 

eInvoker: 调用 者 ， 它 持 有 一 个 命令 对 象 ， 并 且 可 以 在 需要 的 时 候 
通过 命令 对 象 完成 具体 的 业务 逻辑 。 

从 上 面 的 示例 中 ， 我 们 可 以 看 到 ， 调 用 者 Invoker 与 操作 者 Receiver 通 
过 Command 命 令 接 口 实现 了 解 厢 。 对 于 调用 者 来 说 ， 我 们 可 以 为 其 注入 
多 个 命令 操作 ， 比 如 新 建文 件 、 复 制 文件 、 删 除 文 件 这 样 三 个 操作 ， 调 
用 者 只 需 在 需要 的 时 候 直 接 调 用 即 可 ， 而 不 需要 知道 这 些 操作 命令 实际 
是 如 何 实现 的 。 而 在 这 里 所 提 到 的 HystrixCommand 和 
HystrixObservableCommand 则 是 在 Hystrix 中 对 Command 的 进一步 抽象 定 
0 
原理 。 

从 上 面 的 示例 中 我 们 也 可 以 发 现 ，Invoker 和 Receiver 的 关系 非常 类 似 
0 所 以 它 比 较 适用 于 实现 记录 日 志 、 撤 销 操 作 、 队 列 
请 求 等 。 

在 下 面 这 些 情况 下 应 考虑 使 用 命令 模式 。 

e 使 用 命令 模式 作为 “回调 (CallBack) ”在 面向 对 象 系统 中 的 替 
代 。“CallBack” 讲 的 便 是 先 将 一 个 函数 登记 上 ， 然 后 在 以 后 调用 此 函 


数 。 

e 需 要 在 不 同 的 时 间 指 定 请 求 、 将 请 求 排队 。 一 个 命令 对 象 和 原先 的 
请 求 用 出 者 可 以 有 不 同 的 生命 期 。 换 言 之 ， 原 先 的 请 求 发 出 者 可 能 已 经 
不 在 了 ， 而 命令 对 象 本 身 仍然 是 活动 的 。 这 时 命令 的 接收 者 可 以 是 在 本 
地 ， 也 可 以 在 网 络 的 另外 一 个 地 址 。 命 令 对 象 可 以 在 序列 化 之 后 传送 到 
另外 一 人 台 机 器 上 去 。 

e 系 统 需要 支持 命令 的 撤销 。 命 令 对 象 可 以 把 状态 存储 起 来 ， 等 到 客 
户 问 需要 撤销 命令 所 产生 的 效果 时 ， 可 以 调用 undo 〈) 方法 ， 把 命令 
所 产生 的 效果 撤销 控 。 命 令 对 象 还 可 以 提供 redo() 方法 ， 以 供 客户 站 
在 需要 时 再 重新 实施 命令 效果 。 














e 如 果 要 将 系统 中 所 有 的 数据 更 新 到 日 志 里 ， 以 便 在 系统 朋 溃 时 ， 可 
以 根据 日 志 读 回 所 有 的 数据 更 新 命令 ， 重 新 调用 “Execute 〈) 方法 一 条 
一 条 执行 这 些 命 令 ， 从 而 恢复 系统 在 朋 泪 前 所 做 的 数据 更 新 。 

2. 命 令 执行 

从 图 中 我 们 可 以 看 到 一 共存 在 4 种 命令 的 执行 方式 ， 而 Hystrix 在 执行 
时 会 根据 创建 的 Command 对 象 以 及 具体 的 情况 来 选择 一 个 执行 。 其 中 
HystrixCommand 实 现 了 下 面 两 个 执行 方式 。 

eexecute () : 同步 执行 ， 从 依赖 的 服务 返回 一 个 单一 的 结果 对 象 ， 
或 是 在 发 生 错 误 的 时 候 抛 出 异常 。 

edueue〈) : 异步 执行 ， 直 接 返回 一 个 Future 对 象 ， 其 中 包含 了 服务 
执行 结束 时 要 返回 的 单一 结果 对 象 。 

R value=command.execute () ; 

Future<R> fValue=command.queue 〈) ; 

而 HystrixObservableCommand 实 现 了 另外 两 种 执行 方式 。 

e@observe () : 返回 Observable 对 象 ， 它 代表 了 操作 的 多 个 结果 ， 
它 是 一 个 Hot Observable。 

etoObservable () : 同样 会 返回 Observable 对 象 ， 也 代表 了 操作 的 多 
个 结果 ， 但 它 返 回 的 是 一 个 Cold Observable。 

Observable<R> ohValue=command.observe () ; 

Observable<R> ocValue=command.toObservable () ; 

在 Hystrix 的 底层 实现 中 大 量 地 使 用 了 RxJava， 为 了 更 容易 地 理解 后 
续 内 容 ， 在 这 里 对 RxJava 的 观察 者 -订阅 者 模式 做 一 个 简单 的 入 门 介 


绍 

上 面 我 们 所 提 到 的 Observable 对 象 束 是 RxJava 中 的 核心 内 容 之 一 ， 可 
以 把 它 理 解 为 “事件 源 ? 或 是 “被 观察 者 ”， 与 其 对 应 的 Subscriber 对 象 ， 可 
以 理解 为 “订阅 者 ?或 是 “观察 者 ”。 这 两 个 对 象 是 RxJava 吧 应 式 编 程 的 重 
要 组 成 部 分 。 

eObservable 用 来 向 订阅 者 Subscriber 对 象 发 布 事 件 ，Subscriber 对 象 
人 而 在 这 里 所 指 的 事件 通常 就 是 对 依赖 

J 调用 。 

e 一 个 Observable 可 以 及 出 多 个 事件 ， 直 到 结束 或 是 发 生 异 币 。 

eObservable 对 象 每 发 出 一 个 事件 ， 就 会 调用 对 应 观察 者 Subscriber 
对 象 的 onNext() 方法 。 

e 每 一 个 Observable 的 执行 ， 最 后 一 定 会 通过 调用 
Subscriber.onCompleted 〈) 或 者 Subscriber.onError () 来 结束 该 事件 的 
操作 流 。 

下 面 我 们 通过 一 个 简单 的 例子 来 直观 理解 一 下 Observable 与 




















Subscribers: 

// 创 建 事件 源 observable 

Observable<String> observable=Observable.create (new 
Observable.OnSubscribe<String> () { 

(DOverride 

public void call (Subscriber<? super String> subscriber) { 

subscriber.onNext ("Hello RxJava") ; 

subscriber.onNext ("I am 程序 猿 DD") : 

subscriber.onCompleted () ; 

} 

Dn 

// 创 建 订阅 者 subscriber 

Subscriber<String> subscriber=new Subscriber<String> () { 

(DOverride 

public void onCompleted () { 

} 

(DOverride 

public void onError (Throwable e) { 

} 

(OOverride 

public void onNext (Strings) { 

System.out.println ("Subscriber : "+S) ; 


}; 

/订阅 

observable.subscribe (subscriber) ; 

在 该 示例 中 ， 创 建 了 一 个 简单 的 事件 源 observable， 一 个 对 事件 传递 
内 容 输出 的 订阅 者 subscriber， 通 过 observable.subscribe (subscriber) 来 
触发 事件 的 发 布 。 

在 这 里 我 们 对 于 事件 源 ”observable ” 提 到 了 两 个 不 同 的 概念 ， Hot 
Observable 和 Cold Observable， 分 别 对 应 了 上 面 command.observe () 和 
command.toObservable 〈) 的 返回 对 象 。 其 中 Hot Observable， 它 不 
论 “ 事 件 源 ?是否 有 “订阅 者 >”， 都 会 在 创建 后 对 事件 进行 发 布 ， 所 以 对 于 
Hot Observable 的 每 一 个 “订阅 者 ”都 有 可 能 是 从 “事件 源 ” 的 中 途 开 始 的 ， 
并 可 能 只 是 看 到 了 整个 操作 的 局 部 过 程 。 而 Cold Observable 在 没有 “订阅 
者 ”的 时 候 并 不 会 发 布 事件 ， 而 是 进行 等 待 ， 直 到 有 “订阅 者 ”之 后 才 发 
布 事件 ， 所 以 对 于 Cold Observable 的 订阅 者 ， 它 可 以 保证 从 一 开始 看 到 














整个 操作 的 全 部 过 程 。 

大 家 从 表面 上 可 能 会 认为 只 是 在 HystrixObservableCommand 中 使 用 
了 RxJava， 然 而 实际 上 execute () 、gueue() 也 都 使 用 了 RxJava 来 实 
现 。 从 下 面 的 源码 中 我 们 可 以 看 到 : 

eexecute 〈) 是 通过 queue() 返回 的 异步 对 象 Future<R> 的 get () 方 
法 来 实现 同步 执行 的 。 该 方法 会 等 待 任务 执行 结束 ， 然 后 获得 R 类 型 的 
结果 进行 返回 。 

edqueue () 则 是 通过 toObservable () 来 获得 一 个 Cold Observable， 
并 且 通 过 toBlocking〈) 将 该 Observable 转 换 成 BlockingObservable， 它 
可 以 把 数据 以 阻塞 的 方式 发 射出 来 。 而 toFuture 方法 则 是 把 
BlockingObservable ”转换 为 一 个 Future， 该 方法 只 是 创建 一 个 Future 返 
回 ， 并 不 会 阻塞 ， 这 使 得 消费 者 可 以 自己 决定 如 何 处 理 异 步 操作 。 而 
execute () 就 是 直接 使 用 了 queue 〈) 返回 的 Future ”中 的 阻塞 方法 
get〈) 来 实现 同步 操作 的 。 同 时 通过 这 种 方式 转换 的 Future 要 求 
Observable 只 发 射 一 个 数据 ， 所 以 这 两 个 实现 都 只 能 返回 单一 结 

public R execute () { 

try { 

return queue () .get (); 

} catch (Exception e) { 

throw decomposeException (e) ; 

} 

} 

public Future<R> queue () { 

final Observable<R> o=toObservable (); 

final Future<R> f=0.toBlocking () .toFuture 〈) ; 

if (fisDone () ) { 

/处 理 立 即 抛 出 的 错误 





} 


return f; 


} 

3. 结 果 是 否 被 缓存 

藻 当 前 命令 的 请 求 缓存 功能 是 被 启用 的 ， 并 且 该 命令 缓存 命中 ， 那 
么 缓存 的 结果 会 立即 以 Observable 对 象 的 形式 返回 。 

4. 断 路 器 是 否 打开 

在 命令 结果 没有 缓存 命中 的 时 候 ，Hystrix 在 执行 命令 前 需要 检查 断 
路 堪 是 人 否 为 打开 状态 : 








e 如 果断 路 器 是 打开 的 ， 那 么 Hystrix 不 会 执行 命令 ， 而 是 转 接 到 
fallback 处 理 逻 辑 〈 对 应 下 面 第 8 步 ) 。 

e 如 果断 路 器 是 关闭 的 ， 那 么 Hystrix 跳 到 第 5 步 ， 检 查 是 否 有 可 用 资 
源 来 执行 命令 。 

关于 断路 右 的 具体 实现 细节 ， 后 续 会 做 更 加 详细 的 分 析 。 

5. 线 程 池 / 请 求 队 列 /信号 量 是 否 占 满 

如 采 与 命令 相关 的 线程 池 和 请 求 队 列 ， 或 者 信号 量 〈 不 使 用 线程 池 
的 时 候 ) 已 经 被 占 满 ， 那 么 Hystrix 也 不 会 执行 命令 ， 而 是 转 接 到 
fallback 处 理 逻 辑 (对 应 下 面 第 8 步 〉。 

需要 注意 的 是 ， 这 里 Hystrix 所 判断 的 线程 池 并 非 容 如 的 线程 池 ， 而 
是 每 个 依赖 服务 的 专 有 线程 池 。Hystrix 为 了 保证 不 会 因为 某 个 依赖 服务 
的 问题 影响 到 其 他 依赖 服务 而 采用 了 “ 舱 壁 模式 ”(Bulkhead Pattern) 来 
隔离 每 个 依赖 的 服务 。 关 于 依赖 服务 的 隔离 与 线程 池 相 关 的 内 容 见 后 续 
详细 介绍 。 

6.HystrixObservableCommand.construct () 或 
HystrixCommand.run () 


Ts 的 方法 来 决定 采取 什么 样 的 方式 去 请 求 依赖 
及 务 。 


eHystrixCommand.ruan〈) : 返回 一 个 单一 的 结果 ， 或 者 抛 出 异 肖 。 

eHystrixObservableCommand.construct() : 返回 一 个 Observable 对 
象 来 上 友 射 多 个 结果 ， 或 通过 onError 发 送 错 误 通 知 。 

如 果 run 〈) 或 construct〈) 方法 的 执行 时 间 超 过 了 命令 设置 的 超时 
国 值 ， 当 前 处 理 线程 将 会 抛 出 一 个 _TimeoutException (如 果 该 命令 不 在 
其 自身 的 线程 中 执行 ， 则 会 通过 单独 的 计时 线程 来 扫 出 ) 。 在 这 种 情况 
下 ，Hystrix 会 转 接 到 fallback 处 理 逻 辑 (第 8 步 ) 。 同 时 ， 如 有 果 当 前 命令 
没有 被 取消 或 中 断 ， 那 么 它 最 终 会 忽略 rmmn〈() 或 者 construct() 方法 的 
返回 。 

如 果 命 令 没 有 抛 出 异常 并 返回 了 结果 ， 那 么 Hystrix 在 记录 一 些 日 志 
并 采集 监控 报告 之 后 将 该 结果 返回 。 在 使 用 run《〈) 的 情况 下 ，Hystrix 
会 返回 一 个 Observable， 它 发 射 单 个 结 末 并 产生 onCompleted 的 结束 通 
知 ; 而 在 使 用 construct 〈) 的 情况 下 ，Hystrix 会 直接 返回 该 方法 产生 的 
Observable 对 象 。 

7. 计 算 断 路 器 的 健康 度 

Hystrix 会 将 “成 功 "、“ 失 败 ”"”、“ 拒 绝 ”、“ 超 时 ”等 信息 报告 给 断路 器 ， 
而 断路 器 会 维护 一 组 计数 器 来 统计 这 些 数据 。 

断路 器 会 使 用 这 些 统计 数据 来 决定 是 否 要 将 断路 器 打开 ， 来 对 某 个 
依赖 服务 的 请 求 进行 “熔断 /短路 "”， 直 到 恢复 期 结束 。 知 在 恢复 期 结束 









































后 ， 根 据 统计 数据 判断 如 果 还 是 未 达到 健康 指标 ， 就 再 次 “熔断 /短路 ”。 

8.fallback 处 理 

当 命 令 执行 失败 的 时 候 ，Hystrix 会 进入 fallback 演 试 回 退 处 理 ， 我 们 
ee 而 能 够 引起 服务 降级 处 理 的 情况 有 下 面 
几 种 : 

e 第 4 步 ， 当 前 命令 处 于 “和 熔断/ 短路? 状态， 断路 堪 是 打开 的 时 候 。 

e 第 5 步 ， 当 前 命令 的 线程 池 、 请 求 队列 或 者 信号 量 被 占 满 的 时 候 。 

e 第 6 步 ，HystrixObservableCommand.construct 〈) 或 
HystrixzCommandrun〈) 抛 出 异常 的 时 候 。 

在 服务 降级 逻辑 中 ， 我 们 需要 实现 一 个 通用 的 啊 应 结果 ， 并 且 该 结 
果 的 处 理 逻 辑 应 当 是 从 绥 存 或 是 根据 一 些 静 态 逻 辑 来 获取 ， 而 不 是 依赖 
网 络 请 求 获取 。 如 有 果 一 定 要 在 降级 逻辑 中 包含 网 络 请 求 ， 那 么 该 请 求 也 
必须 被 包装 在 HystrixCommand 或 是 HystrixObservableCommand 中 ， 从 而 
形成 级 联 的 降级 策略 ， 而 最 终 的 降级 多 辑 一 定 不 是 一 个 依赖 网 络 请 求 的 
处 理 ， 而 是 一 个 能 够 稳定 地 返回 结果 的 处 理 逻 辑 。 

在 HystrixCommand 和 HystrixObservableCommand 中 实现 降级 逻辑 时 
还 略 有 不 同 : 

e@ 当 使 用 HystrixCommand 的 时 候 ， 通 过 实现 
HystrixCommand.getFallback () 来 实现 服务 降级 逻辑 。 

e 当 使 用 HystrixObservableCommand 的 时 候 ， 通 过 
HystrixObservableCommand.resumeWithFallback () 实现 服务 降级 逻 
辑 ， 访 方法 会 返回 一 个 Observable 对 象 来 发 射 一 个 或 多 个 降级 结 

当 命 令 的 降级 逻辑 返回 结果 之 后 ，Hystrix ”就 将 该 结果 返回 给 调用 
者 。 当 使 用 HystrixCommand.getFallback〈) 的 时 候 ， 它 会 返回 一 个 
Observable 对 象 ， 该 对 象 会 发 射 ”getFallback() 的 处 理 结果 。 而 使 用 
HystrixObservableCommand.resumeWithFallback〈) 实现 的 时 候 ， 它 会 
将 Observable 对 象 直 接 返 回 。 

如 有 果 我 们 没有 为 命令 实现 降级 逻辑 或 者 降级 处 理 逻 辑 中 抛 出 了 异 
常 ，Hystrix 依 然 会 返回 一 个 Observable 对 象 ， 但 是 它 不 会 发 射 任何 结 
数据 ， 而 是 通过 onError 方 法 通知 命令 立即 中 断 请 求 ， 并 通过 
onError〈) 方法 将 引起 命令 失败 的 异常 发 送 给 调用 者 。 实 现 一 个 有 可 能 
失败 的 降级 逻辑 是 一 种 非常 糟糕 的 做 法 ， 我 们 应 该 在 实现 降级 策略 时 尽 
可 能 避免 失败 的 情况 。 

当然 完全 不 可 能 出 现 失 败 的 完美 策略 是 不 存在 的 ， 如 果 降 级 执行 发 
现 失败 的 时 候 ，Hystrix 会 根据 不 同 的 执行 方法 做 出 不 同 的 处 理 。 

eexecute () : 抛 出 异 名 。 

edqueue () : 正常 返回 Future 对 象 ， 但 是 当 调 用 get 〈) 来 获取 结 























的 时 候 会 抛 出 异常 。 

eobserve() : 正常 返回 Observable 对 象 ， 当 订阅 它 的 时 候 ， 将 立即 
通过 调用 订阅 者 的 onError 方 法 来 通知 中 止 请 求 。 

etoObservable () : 正常 返回 Observable 对 象 ， 当 订阅 它 的 时 候 ， 将 
通过 调用 订阅 者 的 onError 方 法 来 通知 中 止 请 求 。 

9. 返 回 成 功 的 啊 应 

当 Hystrix 命 令 执 行 成 功 之 后 ， 它 会 将 处 理 结果 直接 返回 或 是 以 
Observable 的 形式 返回 。 而 具体 以 哪 种 方式 返回 取决 于 之 前 第 2 步 中 我 们 
所 提 到 的 对 命令 的 4 种 不 同 执行 方式 ， 下 图 中 总 结 了 这 4 种 调用 方式 之 间 
的 依赖 关系 。 我 们 可 以 将 此 图 与 在 第 2 步 中 对 前 两 者 源码 的 分 析 联 系 起 
来 ， 并 且 从 源头 toObservable 〈) 来 开始 分 析 。 对 于 Hystrix 命 令 的 啊 应 
虽然 总 是 以 Observable 的 形式 来 返回 ， 但 是 它 可 以 被 转换 成 你 需要 的 使 
用 方式 来 进行 命令 调用 。 








‘toBlocking( ) 


etoObservable () : 返回 最 原始 的 ”Observable， 必 须 通 过 订阅 它 才 
会 真正 触发 命令 的 执行 流程 。 

eobserve () : 在 toObservable 〈) 产生 原始 Observable 之 后 立即 订 
向 它 ， 让 命令 能 够 马上 开始 异步 执行 ， 并 返回 一 个 Observable 对 象 ， 当 
调用 它 的 subscribe 时 ， 将 重新 产生 结果 和 通知 给 订阅 者 。 

equeue () : 将 toObservable〈) 产生 的 原始 Observable 通 过 
toBlocking() 方法 转换 成 BlockingObservable ” 对象 ， 并 调用 它 的 
toFuture 〈) 方法 返回 异步 的 Future 对 象 。 

eexecute () : 在 queue 〈) 产生 异步 结果 Future 对 象 之 后 ， 通 过 调用 
get〈) 方法 阻塞 并 等 待 结果 的 返回 。 


寺 EE 于 


断路 器 在 HystrixCommand 和 HystrixObservableCommand 执 行 过 程 中 
起 到 了 举足轻重 的 作用 ， 它 是 Hystrix 的 核心 部 件 。 那 么 断路 器 是 如 何 决 





策 熔 新 和 记录 信息 的 呢 ? 

我 们 先 来 看 看 断路 器 HystrixCircuitBreaker 的 定义 : 

public interface HystrixCircuitBreaker { 

public static class Factory {...} 

static class HystrixCircuitBreakerImpl] implements HystrixCircuitBreaker 
La 

static class NoOpCircuitBreaker implements HystrixCircuitBreaker {...} 

public boolean allowRequest (); 

public boolean isOpen (); 

void markSuccess (); 


} 
可 以 看 到 它 的 接口 定义 并 不 复杂 ， 主 要 定义 了 三 个 断路 器 的 抽象 方 


eallowRequest () : 每 个 Hystrix 命 令 的 请 求 都 通过 它 判断 是 否 被 执 








eisOpen () : 返回 当前 断路 器 是 否 打开 。 

emarkSuccess () : 用 来 闭合 断路 右 。 

另外 还 有 三 个 静态 类 。 

e 评 人 态 类 Factory 中 维护 了 一 个 Hystrix 命 令 与 HystrixCircuitBreaker 的 关 
系 集合 : ConcurrentHashMap<String,HystrixCircuitBreaker> 
circuitBreakersByCommand， 其 中 String 类 型 的 key 通 过 
HystrixCommandKey 定 义 ， 每 一 个 Hystrix 命 令 需 要 有 一 个 key 来 标识 ， 
同时 一 个 Hystrix 命 令 也 会 在 该 集合 中 找到 它 对 应 的 断路 器 
HystrixCircuitBreaker 实 例 。 

e 静 态 类 NoOpCircuitBreaker 定 义 了 一 个 什么 都 不 做 的 断路 器 实现 ， 
它 人 允许 所 有 请 求 ， 并 且 断 路 器 状态 始终 闭合 。 

e 静 态 类 HystrixCircuitBreakerImp1] 是 断路 器 接口 HystrixCircuitBreaker 
的 实现 类 ， 在 该 类 中 定义 了 断路 器 的 4 个 核心 对 象 。 

加 HystrixCommandProperties properties: 断路 堪 对 应 HystrixCommand 
实例 的 属性 对 象 ， 它 的 详细 内 容 我 们 将 在 后 续 章 节 做 具体 的 介绍 。 

加 HystrixCommandMetrics metrics: 用 来 让 HystrixCommand 记录 各 类 
度量 指标 的 对 象 。 

AtomicBoolean circuitOpen: 断路 霹 是 否 打开 的 标志 ， 默 认为 
false。 

国 AtomicLong circuitOpenedOrLastTestedTime: 断路 器 打开 或 是 上 一 
次 测试 的 时 间 惟 。 

HystrixCircuitBreakerImpl 对 HystrixCircuitBreaker 接 口 的 各 个 方法 实 





现 如 下 所 示 。 

eisOpen () : 判断 断路 器 的 打开 /关闭 状态 。 详 细 逮 辑 如 下 所 示 。 

四 如 果 汤 路 器 打开 标识 为 tue， 则 直接 返回 true， 表 示 断 路 器 处 于 打 
开 状 态 。 否 则 ， 就 从 度量 指标 对 象 metrics 中 获取 HealthCounts 统 计 对 象 
做 进一步 判断 (该 对 象 记 录 了 一 个 深 动 时 间 窗 内 的 请 求 信息 快照 ， 默 认 
时 间 窗 为 10 秒 ) 。 

口 如 果 它 的 请 求 总 数 〈QPS) 在 预 设 的 浆 值 范围 内 就 返回 false， 表 示 
断路 器 处 于 未 打开 状态 。 该 赋 值 的 配置 参数 为 
circuitBreakerRequestVolumeThreshold， 默 认 值 为 20。 

口 如 条 错误 百分比 在 较 值 范围 内 就 返回 false， 表 示 断 路 器 处 于 未 打开 
状态 。 该 浆 值 的 配置 参数 为 circuitBreakerErrorThresholdPercentage， 默 
认 值 为 50。 

口 如 果 上 面 的 两 个 条 件 都 不 满足 ， 则 将 断路 器 设置 为 打开 状态 〈 熔 
靳 /短路 ) 。 同 时 ， 如 果 是 从 关闭 状态 切换 到 打开 状态 的 话 ， 融 将 当前 
时 间 记 录 到 上 面 提 到 的 circuitOpenedOrLastTestedTime 对 象 中 。 

public boolean isOpen () { 

if (circuitOpen.get () ) { 

return true; 

} 

HealthCounts health=metrics.getHealthCounts (); 

if (health.getTotalRequests () < 

properties.circuitBreakerRequestVolumeThreshold () .get () ) { 

return false; 














if (health.getErrorPercentage () < 

properties.circuitBreakerErrorThresholdPercentage () .get () ) 
{return false; 

} else { 

if (circuitOpen.compareAndSet (false,true) ) { 

circuitOpenedOrLastTestedTime.set (System.currentTimeMillis () ); 

return true; 

} else { 

return true; 

} 

} 

} 

eallowRequest () : 判断 请 求 是 否 补 允许， 这 个 实现 非常 简单 。 先 





根据 配置 对 象 properties 中 的 断路 器 判断 强制 打开 或 关闭 属性 是 人 否 被 设 
置 。 如 果 强 制 打开 ， 就 直接 返回 false， 拒 绝 请 求 。 如 果 强 制 关 闭 ， 它 会 
允许 所 有 请 求 ， 但 是 同时 也 会 调用 isOpen 〈) 来 执行 断路 器 的 计算 好 
辑 ， 用 来 模拟 断路 器 打开 /关闭 的 行为 。 在 默认 情况 下 ， 靳 路 器 并 不 会 
进入 这 两 个 强制 打开 或 关闭 的 分 文中 去 ， 而 是 通过 ! isOpen () || 
allowSingleTest( ) 来 判断 是 否 人 允许 请 求 访 问 。! isOpen 〈) 之 前 已 经 介 
绍 过 ， 用 来 判断 和 计算 当前 断路 器 是 否 打开 ， 如 采 是 断 开 状态 就 允许 请 
求 。 那 么 allowSingleTest 〈) 是 用 来 做 什么 的 呢 ? 

(DOverride 

public boolean allowRequest () { 

if (properties.circuitBreakerForceOpen () .get () ) { 

return false; 

} 

if (properties.circuitBreakerForceClosed () .get () ) { 

isOpen (); 

return true; 

} 

return ! isOpen () ||allowSingleTest (); 


} 

从 allowSingleTest《〈) 的 实现 中 我 们 可 以 看 到 ， 这 里 使 用 了 在 
isOpen 〈) 函数 中 当 断 路 右 从 闭合 到 打开 时 候 所 记录 的 时 间 戳 。 当 断路 
器 在 打开 状态 的 时 候 ， 这 里 会 判断 断 开 时 的 时 间 戳 + 配置 中 的 
circuitBreakerSleepWindowInMilliseconds 时 间 是 否 小 于 当前 时 间 ， 是 的 
话 ， 就 将 当前 时 间 更 新 到 记录 断路 器 打开 的 时 间 对 象 
circuitOpenedOrLastTestedTime 中， 并且 人 允许 此 次 请 求 。 简 单 地 说 ， 通 
过 circuitBreakerSleepWindowInMilliseconds 属性 设置 了 一 个 断路 器 打开 
之 后 的 休眠 时 间 《〈 默 认为 5 秒 ) ， 在 该 休眠 时 间 到 达 之 后 ， 将 再 次 允许 
请 求 答 试 访问 ， 此 时 断路 右 处 于 “ 半 开 ?状态 ， 帮 此 时 请 求 继续 失败 ， 断 
路 器 又 进入 打开 状态 ， 并 继续 等 待 下 一 个 休眠 窗口 过 去 之 后 再 次 答 试 ; 
耕 请 求 成 功 ， 则 将 断路 器 重新 置 于 关闭 状态 。 所 以 通过 
allowSingleTest〈) 与 isOpen() 方法 的 配合 ， 实 现 了 断路 器 打开 和 关 
闭 状态 的 切换 。 

public boolean allowSingleTest () { 

long 
timeCircuitOpenedOrWasLastTested=circuitOpenedOrLastTestedTime.get ( 

if (circuitOpen.get () && System.currentTimeMillis () > 

timeCircuitOpenedOrWasLastTested+ 


properties.circuitBreakerSleepWindowInMilliseconds () .get () ) { 
if (circuitOpenedOrLastTestedTime.compareAndSet ( 
timeCircuitOpenedOrWasLastTested,System.currentTimeMillis () ) ) 


return true; 

} 

} 

return false; 

} 

emarkSuccess〈) : 该 函数 用 来 在 “ 半 开 路 ”状态 时 使 用 。 知 Hystrix 
人 成 功 ， 通 过 调用 它 将 打开 的 断路 器 关闭 ， 并 重 置 度量 指标 对 








public void markSuccess () { 

if (circuitOpen.get () ) { 

if (circuitOpen.compareAndSet (true,false) ) { 
metrics.resetStream (); 

} 

} 





} 
下 图 是 Netflix Hystrix 官 方 文档 中 关于 断路 占 的 详细 执行 逻辑 ， 可 以 
帮助 我 们 理解 上 面 的 分 析 内 容 。 





Yes. Sleep is passed. Allow | request (return true on | thread) 











No, return false 


(failure) / (success +failure) = % of errors 上 % > threshold, trip circuic rerurn true, else false 





Get htest bucket and increment “success” or “latent” 


markfFailure({duration) 


| 10 1-second "buckets” 


26 48 38 42 
4 9 4 6 
0 4 2 7 
0 0 0 0 


On getLarestBucker if the |-second window is passed a new bucker is created, the rest slid over and the oldest one dropped. 


Na 








条 互信 


“ 舱 壁 模式 ?对 于 熟悉 Docker 的 读者 一 定 不 陌生 ，Docker 通 过 “ 舱 壁 模 
式 ” 实 现 进程 的 隔离 ， 使 得 容器 与 容器 之 间 不 会 互相 影响 。 而 Hystrix 则 
使 用 该 模式 实现 线程 池 的 隔离 ， 它 会 为 每 一 个 依赖 服务 创建 一 个 独立 的 
线程 池 ， 这 样 就 算 某 个 依赖 服务 出 现 延 迟 过 高 的 情况 ， 也 只 是 对 该 依赖 
服务 的 调用 产生 影响 ， 而 不 会 拖 慢 其 他 的 依赖 服务 。 

通过 实现 对 依赖 服务 的 线程 池 隔 离 ， 可 以 带 来 如 下 优势 : 

e 应 用 自 丑 得 到 完全 保护 ， 不 会 受 不 可 控 的 依赖 服务 有 影响。 即便 给 依 
赖 服 务 分 配 的 线程 池 被 填 满 ， 也 不 会 影响 应 用 自身 的 其 余部 分 。 

e 可 以 有 效 降低 接 入 新 服务 的 风险 。 如 果 新 服务 接 入 后 运行 不 稳定 或 
存在 问题 ， 完 全 不 会 影响 应 用 其 他 的 请 求 。 

e 当 依赖 的 服务 从 失效 恢复 正常 后 ， 它 的 线程 池 会 被 清理 并 且 能 够 马 
上 恢复 健康 的 服务 ， 相 比 之 下 ， 容 右 级 别 的 清理 恢复 速度 要 慢 得 多 。 























e 当 依赖 的 服务 出 现 配置 错误 的 时 候 ， 线 程 池 会 快速 反映 出 此 问题 
(通过 失败 次 数 、 延 人 运 、 超 时 、 拒 绝 每 指标 的 增加 情况 )。 同 时 ， 我 们 
可 以 在 不 影响 应 用 功能 的 情况 下 通过 实时 的 动态 属性 刷新 (后 续 会 通过 
Spring Cloud Config 与 Spring Cloud Bus 的 联合 使 用 来 介绍 ) 来 处 理 它 。 

e 当 依赖 的 服务 因 实现 机 制 调整 等 原因 造成 其 性 能 出 现 很 大 变化 的 时 
候 ， 线 程 池 的 监控 指标 信息 会 反映 出 这 样 的 变化 。 同 时 ， 我 们 也 可 以 通 
| 自身 应 用 对 依赖 服务 的 靖 值 进行 调整 以 适应 依赖 方 的 改 


e 除 了 上 上面 通 过 线程 池 隔 离 服 务 发 挥 的 优点 之 外 ， 每 个 专 有 线程 池 都 
提供 了 内 置 的 并 发 实现 ， 可 以 利用 它 为 同步 的 依赖 服务 构建 异步 访问 。 
总 之 ， 通 过 对 依赖 服务 实现 线程 池 隔 离 ， 可 让 我 们 的 应 用 更 加 健 
壮 ， 不 会 因为 个 别 依赖 服务 出 现 问题 而 引起 非 相 关 服 务 的 异常 。 同 时 ， 
也 使 得 我 们 的 应 用 变 得 更 加 灵活 ， 可 以 在 不 停止 服务 的 情况 下 ， 配 合 动 

态 配置 刷新 实现 性 能 配置 上 的 调整 。 

虽然 线程 池 隔 离 的 方案 融 来 如 此 多 的 好 处 ， 但 是 很 多 使 用 者 可 能 会 
担心 为 每 一 个 依赖 服务 都 分 配 一 个 线程 池 是 否 会 过 多 地 增加 系统 的 负载 
和 开销 。 对 于 这 一 点 ， 使 用 者 不 用 过 于 担心 ， 因 为 这 些 顾 虑 也 是 大 部 分 
工程 师 们 会 考虑 到 的 ，Netflix 在 设计 Hystrix 的 时 候 ， 认 为 线程 池上 的 开 
销 相 对 于 隔离 所 带 来 的 好 人 处 是 无 法 比拟 的 。 同 时 ，Netflix 也 针对 线程 池 
的 开销 做 了 相关 的 测试 ， 以 用 结果 打消 Hystrix 实 现 对 性 能 影响 的 顾虑 。 

下 图 是 Netflix Hystrix 官 方 提供 的 一 个 Hystrix 命 令 的 性 能 监控 图 ， 该 
命令 以 每 秒 60 个 请 求 的 速度 (QPS) 对 一 个 单 服 务实 例 进行 访问 ， 该 服 
务实 例 每 秒 运行 的 线程 数 峰 值 为 350 个 。 
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从 图 中 的 统计 我 们 可 以 看 到 ， 使 用 线程 池 隔 离 与 不 使 用 线程 池 隔 离 
的 耗 时 差异 如 下 表 所 示 : 
所 

















在 99% 的 情况 下 ， 使 用 线程 池 隔 离 的 延迟 有 9ms， 对 于 大 多 数 需求 来 
说 这 样 的 消耗 是 微乎其微 的 ， 更 何况 可 为 系统 在 稳定 性 和 灵活 性 上 带 来 
巨大 的 提升 。 虽 然 对 于 大 部 分 的 请 求 我 们 可 以 忽略 线程 池 的 额外 开销 ， 








而 对 于 小 部 分 延迟 本 身 就 非常 小 的 请 求 〈 可 能 只 需要 lms) ， 那 么 9ms 
的 延迟 开销 还 是 非常 昂贵 的 。 实际 上 Hystrix 也 为 此 设计 了 男 外 的 解决 方 
在 Hystrix 中 除了 可 使 用 线程 池 之 外 ， 还 可 以 使 用 信号 量 来 控制 单个 
依赖 服务 的 并 发 度 ， 信 号 量 的 开销 远 比 线程 池 的 开销 小 ， 但 是 它 不 能 设 
置 超时 和 实现 异步 访问 。 所 以 ， 只 有 在 依赖 服务 是 足够 可 靠 的 情况 下 才 
使 用 信号 量 。 在 HystrixCommand 和 HystrixObservableCommand 中 有 两 
处 文 持 信号 量 的 使 用 。 

e 命 令 执 行 : 如 果 将 隔离 策略 参数 execution.isolation.strategy 设置 为 
ee 信号 量 替 代 线 程 池 来 控制 依赖 服务 的 并 


.降级 违 得 ; 当 Hystrix 和 尝试 降级 逻辑 时 ， 它 会 在 调用 线程 中 使 用 信 
号 量 。 
言 号 量 的 默认 值 为 10， 我 们 也 可 以 通过 动态 刷新 配置 的 方式 来 控制 
并 发 线程 的 数量 。 对 于 信和 号 量 大 小 的 估算 方法 与 线程 池 并 发 度 的 估算 关 
似 。 仅 访问 内 存 数据 的 请 求 一 般 耗 时 在 1ms 以 内 ， 人 性 能 可 以 达到 
5000rps (rps 指 每 秒 的 请 求 数 )， 这 样 级 别 的 请 求 可 以 将 信号 量 设置 为 1 


或 者 2， 我 们 可 以 按 此 标准 并 根据 实际 请 求 耗 时 来 设置 信号 量 。 
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在 “快速 入 门 ” 一 节 中 我 们 已 经 使 用 过 Hystrix 中 的 核心 注解 
@HystrixCommand， 通 过 它 创 建 了 HystrixCommand 的 实现 ， 同 时 利用 
fallback 属 性 指定 了 服务 降级 的 实现 方法 。 然 而 这 些 还 只 是 Hystrix 使 用 
的 一 小 部 分 ， 在 实现 一 个 大 型 分 布 式 系统 时 ， 往 往 还 需要 更 多 高 级 的 配 
置 功 能 。 接 下 来 我 们 将 详细 介绍 Hystrix 各 接口 和 注解 的 使 用 方法 。 


创建 请 求 命令 


Hystrix 命令 就 是 我 们 之 前 所 说 的 HystrixCommand， 它 用 来 封装 具体 
的 依赖 服务 调用 逻辑 。 

我 们 可 以 通过 继承 的 方式 来 实现 ， 比 如 : 

public class UserCommand extends HystrixCommand<User> { 

private RestTemplate restTemplate; 

private Long id; 

public UserCommand (Setter setter,RestTemplate restTemplate,Long 
id) { 

super (setter) ; 

this.restTemplate=restTemplate; 

this.id=id; 

} 

Override 

protected User run () { 

return restTemplate.getForObject ("http://USER- 
SERVICE/users/{1}",User.class,id) : 

} 


} 
通过 上 面 实现 的 UserCommand， 我 们 既 可 以 实现 请 求 的 同步 执行 也 
可 以 实现 异步 执行 。 


e 辣 步 执行 : User U=new 
UserCommand (restTemplate,1lL) .execute () ;。 
ee 异步 执行 : Future<User> futureUser=new 


UserCommand (restTemplate,1L)〉.queue () ;。 异 步 执 行 的 时 候 ， 可 以 
通过 对 返回 的 futureUser 调 用 get 方 法 来 获取 结 


另外 ， 也 可 以 通过 @HystrixCommand 注解 来 更 为 优雅 地 实现 Hystrix 
命令 的 定义 ， 比 如 : 


public class UserService { 


(OAutowired 

private RestTemplate restTemplate; 

@HystrixCommand 

public User getUserByld (Longid) { 

return restTemplate.getForObject ("http://USER- 
SERVICE/users/{1}",User.class,id) : 

} 


} 

里 然 @HystrixCommand 注解 可 以 非常 优雅 地 定义 Hystrix 命令 的 实 
现 ， 但 是 如 上 定义 的 getUserById 方 式 只 是 同步 执行 的 实现 ， 符 要 实现 异 
步 执行 则 还 需 另外 定义 ， 比 如 : 

@HystrixCommand 

public Future<User> getUserByldAsync (final String id) { 

return new AsyncResult<User> () { 

(DOverride 

public User invoke () { 

return restTemplate.getForObject ("http:/USER-SERVICE/users/{1}", 

User.class,id) ; 

} 

和 


} 

除了 传统 的 同步 执行 与 异步 执行 之 外 ， 我 们 还 可 以 将 
HystrixCommand 通过 Observable 来 实现 响应 式 执 行 方式 。 通 过 调用 
observe () 和 toObservable () 方法 可 以 返回 Observable 对 象 ， 比 如 : 


Observable<String> ho=new 
UserCommand (restTemplate,1lL) .observe 〈) ; 
Observable<String> co=new 


UserCommand (restTemplate,1lL) .toObservable (); 

observe () 和 toObservable () 虽然 都 返回 了 Observable， 但 是 它们 
略 有 不 同 ， 前 者 返回 的 是 一 个 Hot Observable， 该 命令 会 在 observe () 
调用 的 时 候 立 即 执行 ， 当 Observable 每 次 被 订阅 的 时 候 会 重 放 它 的 行 
为 ; 而 后 者 返回 的 是 一 个 Cold Observable，toObservable 〈) 执行 之 后 ， 
命令 不 会 被 了 立即 执行 ， 只 有 当 所 有 订阅 者 都 订阅 它 之 后 才 会 执行 。 更 多 
关于 这 两 个 方法 的 区 别 可 见 “ 原 理 分 析 ? 小 节 的 内 容 ， 这 里 不 做 具体 说 








明 。 

虽然 HystrixCommand 具 备 了 observe〈) 和 toObservable() 的 功能 ， 
但 是 它 的 实现 有 一 定 的 局 限 性 ， 它 返回 的 Observable 只 能 发 射 一 次 数 
据 ， 所 以 Hystrix 还 提供 了 另外 一 个 特殊 命令 封装 
HystrixObservableCommand， 通 过 它 实 现 的 命令 可 以 获取 能 发 射 多 次 的 
Observable。 

如 果 使 用 HystrixObservableCommand 来 实现 命令 封装 ， 需 要 将 命令 
的 执行 逻辑 在 construct 方 法 中 重 载 ， 这 样 Hystrix 才 能 将 具体 逻辑 包装 到 
Observable 内 ， 如 下 所 示 : 


Public class UserObservableCommand extends HystrixObservableCommand<User> { 











private RestTemplate restTemplate; 
private Long id; 


Public UserObservableCommand (Setter setter, RestTemplate restTemplate, Long id) 1 
super (setter); 
this.restTemplate = restTemplate; 
this.id = id; 

} 


Override 
protected Observable<User> construct() { 
return Observable.create (new Observable.OnSubscribe<User>() { 
QOverride 
public void call (Subscriber<? super User> observer) I 
try { 
if (!observer.isUnsubscribed()) { 
User user = restTemplate.getForOobject ("http://USER-SERVICE/ 
users/{1}", User.class, id); 
Observer.onNext (user); 
observer.onCompleted(); 
} 
} catch (Exception e) 1{ 
observer.onError (e); 





而 对 此 的 注解 实现 依然 是 使 用 @HystrixCommand， 只 是 方法 定义 需 
要 做 一 些 变 化 ， 具 体内 容 与 construct() 的 实现 类 似 ， 如 下 所 示 : 

@HystrixCommand 

public Observable<User> getUserById (final String id) { 

return Observable.create (new Observable.OnSubscribe<User> () { 


(DOverride 


public void call (Subscriber<? super User> Observer ) { 

try { 

if (! observer.isUnsubscribed () ) { 

User user=restTemplate.getForObject ("http:/HELLO-SERVICE/ 
users/{1}",User.class,id) ， 

observer.onNext (user) ; 

observer.onCompleted () ; 

} 

} catch (Exception e) { 

observer.onError (e) ; 


} 

} 

.se 

} 

在 使 用 @HystrixCommand 注解 实现 啊 应 式 命令 时 ， 可 以 通过 


observableExecutionMode 人 参数 来 控制 是 使 用 observe〈) 还 是 

toObservable〈) 的 执行 方式 。 该 参数 有 下 面 两 种 设置 方式 。 
eOHystrixCommand 〈observableExecutionMode=ObservableExecution] 

是 该 参数 的 模式 值 ， 表 示 使 用 observe() 执行 方式 。 
eQ@HystrixCommand (observableExecution Mode=ObservableExecution] 


表示 使 用 toObservable () 执行 方式 。 


fallback 是 Hystrix 命 令 执行 失败 时 使 用 的 后 备 方法 ， 用 来 实现 服务 的 
降级 处 理 逻 辑 。 在 HystrixCommand 中 可 以 通过 重 载 getFallback() 方法 
来 实现 服务 降级 逻辑 ，Hystrix 会 在 。 run〈) 执行 过 程 中 出 现 错误 、 超 
时 、 线 程 池 拒绝 、 断 路 器 熔断 等 情况 时 ， 执 行 getFallback () 方法 内 的 
逻辑 ， 比 如 我 们 可 以 用 如 下 方式 实现 服务 降级 逻辑 : 

public class UserCommand extends HystrixCommand<User> { 

private RestTemplate restTemplate; 

private Long id; 

public UserCommand (Setter setter,RestTemplate restTemplate,Long 
id) { 

super (setter) ; 

this.restTemplate=restTemplate; 

this.id=id,; 


} 

(OOverride 

protected User run () { 

return restTemplate.getForObject ("http://USER- 
SERVICE/users/{1}",User.class,id) ; 

} 

(DOverride 

protected User getFallback () { 

return new User (); 

} 

， 

在 HystrixObservableCommand 实现 的 Hystrix 命令 中 ， 我 们 可 以 通 
过 重 载 resumeWithFallback 方法 来 实现 服务 降级 馆 辑 。 该 方法 会 返回 一 
个 Observable 对 象 ， 当 命令 执行 失败 的 时 候 ，Hystrix 会 将 Observable 中 
的 结果 通知 给 所 有 的 订阅 者 。 

共 要 通过 注解 实现 服务 降级 只 需要 使 用 @HystrixCommand 中 的 
fallbackMethod 参 数 来 指定 具体 的 服务 降级 实现 方法 ， 如 下 所 示 : 

public class UserService { 

(OAutowired 

private RestTemplate restTemplate; 

@HystrixCommand (fallbackMethod="defaultUser") 

public User getUserByld (Longid) { 

return restTemplate.getForObject ("http://USER- 
SERVICE/users/{1}",User.class,id) : 


} 
public User defaultUser () { 
return new User () ， 


} 


} 

在 使 用 注解 来 定义 服务 降级 逻辑 时 ， 我 们 需要 将 具体 的 Hystrix 命 令 
与 fallback 实 现 函 数 定 义 在 同一 个 类 中 ， 并 且 fallbackMethod 的 值 必 须 与 
实现 fallback 方 法 的 名 字 相 同 。 由 于 必须 定义 在 一 个 类 中 ， 所 以 对 于 
fallback 的 访问 修饰 符 没 有 特定 的 要 求 ， 定 义 为 private、protected、 
public 均 可 。 

在 上 面 的 例子 中 ，defaultUser 方 法 将 在 getUserById 执 行 时 发 生 错误 
的 情况 下 被 执行 。 知 defaultUser 方 法 实现 的 并 不 是 一 个 稳定 逻辑 ， 它 依 
然 可 能 会 发 生 异 利 ， 那 么 我 们 也 可 以 为 它 添加 @HystrixCommand 注解 





以 生成 Hystrix 命令 ， 同 时 使 用 fallbackMethod 来 指定 服务 降级 逻辑 ， 比 
如 : 


public class UserService { 

(OAutowired 

private RestTemplate restTemplate; 
@HystrixCommand (fallbackMethod="defaultUser") 
public User getUserById (Longid) { 


return restTemplate.getForObject ("http://USER- 
SERVICE/users/{1}",User.class,id) : 
} 


@HystrixCommand (fallbackMethod="defaultUserSec") 
public User defaultUser () { 
// 此 处 可 能 是 男 外 一 个 网 络 请 求 来 获取 ， 所 以 也 有 可 能 失败 


return new User ("First Fallback") : 


} 
public User defaultUserSec () { 
return new User ("Second Fallback") : 


} 


} 

在 实际 使 用 时 ， 我 们 需要 为 大 多 数 执行 过 程 中 可 能 会 失败 的 Hystrix 
0 但 是 也 有 一 些 情况 可 以 不 去 实现 降级 逻辑 ， 如 
下 所 示 。 

e 执 行 写 操作 的 命令 : 当 Hystrix 命 令 是 用 来 执行 写 操作 而 不 是 返回 
一 些 信 息 的 时 候 ， 通 常情 况 下 这 类 操作 的 返回 类 型 是 void 或 是 为 空 的 
Observable， 实 现 服 务 降 级 的 意义 不 是 很 大 。 当 写 入 操作 失败 的 时 候 ， 
我 们 通常 只 需要 通知 调用 者 即 可 。 

e 执 行 批 处 理 或 离线 计算 的 命令 ; 。 当 Hystrix 命 令 是 用 来 执行 批 处 理 
程序 生成 一 份 报告 或 是 进行 任何 类 型 的 离线 计算 时 ， 那 么 通常 这 些 操作 
只 需要 将 错误 传播 给 调用 者 ， 然 后 让 调用 者 稍 后 重 试 而 不 是 发 送 给 调用 
者 一 个 静默 的 降级 处 理 啊 应 。 

不 论 Hystrix 命 令 是 否 实现 了 服务 降级 ， 命 令 状 态 和 断路 喜 状 态 都 会 
更 新 ， 并 且 我 们 可 以 由 此 了 解 到 命令 执行 的 失败 情况 。 


异常 处 理 


寞 单传 播 
在 HystrixzCommand 实 现 的 rn〈) 方法 中 抛 出 异常 时 ， 除 了 





HystrixBadRequestException 之 外 ， 其 他 异常 均 会 被 Hystrix 认 为 命令 执行 
失败 并 触发 服务 降级 的 处 理 逻 辑 ， 所 以 当 需 要 在 命令 执行 中 抛 出 不 触发 
服务 降级 的 异常 时 来 使 用 它 。 

而 在 使 用 注册 配置 实现 Hystrix 命 令 时 ， 它 还 支持 忽略 指定 异常 类 型 
功能 ， 只 需要 通过 设置 @HystrixCommand 注 解 的 ignoreExceptions 参 数 ， 
比如 : 

@HystrixCommand (ignoreExceptions={BadRequestException.class}) 

public User getUserById (Longid) { 

return restTemplate.getForObject ("http://USER- 
SERVICE/users/{1}",User.class,id) : 





} 

如 上 面 代码 的 定义 ， 当 getUserById 方法 抛 出 了 类 型 为 
BadRequestException 的 异常 时 ，Hystrix 会 将 它 包 装 在 
HystrixBadRequestException 中 擅 出 ， 这 样 就 不 会 触发 后 续 的 fallback 人 好 
辑 。 

异常 获取 

当 Hystrix 命 令 因 为 异常 (除了 HystrixBadRequestException 的 异常 ) 
进入 服务 降级 逻辑 之 后 ， 往 往 需 要 对 不 同 异 常 做 针对 性 的 处 理 ， 那 么 我 
们 如 何 来 获取 当前 抛 出 的 异 弟 呢 ? 

在 以 传统 继承 方式 实现 的 Hystrix 命令 中 ， 我 们 可 以 用 
getFallback () 方法 通过 Throwable getExecutionException() 方法 来 获 
取 具 体 的 异常 ， 通 过 判断 来 进入 不 同 的 处 理 逻 辑 。 

除了 传统 的 实现 方式 之 外 ， 注 解 配 置 方 式 也 同样 可 以 实现 异常 的 获 
取 。 它 的 实现 也 非常 简单 ， 只 需要 在 fallback 实 现 方 法 的 参数 中 增加 
Throwable e 对 象 的 定义 ， 这 样 在 方法 内 部 就 可 以 获取 触发 服务 降级 的 具 
体 异 常 内 容 了 ， 比 如 : 

@HystrixCommand (fallbackMethod="fallback1") 

User getUserByld (String id) { 

throw new RuntimeException ("getUserByld command failed") ; 

} 

User fallbackl (String id,Throwable e) { 

assert "getUserById command failed".equals (e.getMessage () ) ; 

} 




















命令 名 称 、 分 组 以 及 线程 池 划 分 


以 继承 方式 实现 的 Hystrix 命 令 使 用 类 名 作为 默认 的 命令 名 称 ， 我 们 


也 可 以 在 构造 函数 中 通过 Setter 静 态 类 来 设置 ， 比 如 ; 
public UserCommand () { 
super (Setter.withGroupKey (HystrixCommandGroupKey.Factory.asKe 
.andCommandKey (HystrixCommandKey.Factory.asKey ("CommandN 


} 

从 上 面 Setter 的 使 用 中 可 以 看 到 ， 我 们 并 没有 直接 设置 命令 名 称 ， 
而 是 先 调 用 了 withGroupKey 来 设置 命令 组 名 ， 然 后 才 通 过 调用 
andCommandKey 来 设置 命令 名 。 这 是 因为 在 Setter 的 定义 中 ， 只 有 
withGroupKey 静 态 函 数 可 以 创建 Setter 的 实例 ， 所 以 GroupKey 是 每 个 
Setter 必 有 需 的 参数 ， 而 CommandKey 则 是 一 个 可 选 参数 。 

通过 设置 命令 组 ，Hystrix 会 根据 组 来 组 织 和 统计 命令 的 告警 、 仪 表 
盘 等 信息 。 那 么 为 什么 一 定 要 设置 命令 组 呢 ? 因为 除了 根据 组 能 实现 统 
计 之 外 ，Hystrix 命 令 默 认 的 线程 划分 也 是 根据 命令 分 组 来 实现 的 。 默 认 
情况 下 ，Hystrix 会 让 相同 组 名 的 命令 使 用 同一 个 线程 池 ， 所 以 我 们 需要 
在 创建 Hystrix 命 令 时 为 其 指定 命令 组 名 来 实现 默认 的 线程 池 划 分 。 

如 果 Hystrix 的 线程 池 分 配 仅仅 依靠 命令 组 来 划分 ， 那 么 它 就 显得 不 
够 灵活 了 ， 所 以 Hystrix 还 提供 了 HystrixThreadPoolKey 来 对 线程 池 进 行 
设置 ， 通 过 它 我 们 可 以 实现 更 细 粒 度 的 线程 池 划 分 ， 比 如 : 

public UserCommand () { 

super (Setter.withGroupKey (HystrixCommandGroupKey.Factory.asKe 

("CommandGroupKey") ) 
.andCommandKey (HystrixCommandKey.Factory.asKey ("CommandK 
.andThreadPoolKey (HystrixThreadPoolKey.Factory.asKey ("ThreadPo 


} 

如 果 在 没有 特别 指定 HystrixThreadPoolKey 的 情况 下 ， 依 然 会 使 用 命 
令 组 的 方式 来 划分 线程 池 。 通 常情 况 下 ， 尽 量 通过 
HystrixThreadPoolKey 的 方式 来 指定 线程 池 的 划分 ， 而 不 是 通过 组 名 的 
默认 方式 实现 划分 ， 因 为 多 个 不 同 的 命令 可 能 从 业务 逻辑 上 来 看 属于 同 
一 个 组 ， 但 是 往往 从 实现 本 号 上 需要 跟 其 他 命令 进行 隔离 。 

上 面 已 经 介绍 了 如 何 为 通过 继承 实现 的 HystrixCommand 设置 命令 名 
称 、 分 组 以 及 线程 池 划 分 ， 那 么 当 我 们 使 用 @HystrixCommand 注 解 的 时 
修 ， 又 该 如 何 设置 呢 ?” 只 需 设 置 @HystrixCommand 注 解 的 
commandKey、groupKey 以 及 threadPoolKey 属 性 即 可 ， 它 们 分 别 表示 了 
命令 名 称 、 分 组 以 及 线程 池 划 分 ， 比 如 我 们 可 以 像 下 面 这 样 进行 设置 : 

@HystrixCommand (commandKey="getUserByld",groupKey="UserGrc 

public User getUserByld (Longid) { 

return restTemplate.getForObject ("http://USER- 





SERVICE/users/{1}",User.class,id) : 


当 系 统 用 户 不 断 增长 时 ， 每 个 微服 务 需 要 承受 的 并 友 压 力也 越 来 越 
大 。 在 分 布 式 环 境 下 ， 通 常 压力 来 自 于 对 依赖 服务 的 调用 ， 因 为 请 求 依 
赖 服务 的 资源 需要 通过 通信 来 实现 ， 这 样 的 依赖 方式 比 起 进程 内 的 调用 
方式 会 引起 一 部 分 的 性 能 损失 ， 同 时 HTTP 相 比 于 其 他 高 性 能 的 通信 协 
议 在 速度 上 没有 任何 优势 ， 所 以 它 有 些 类 似 于 对 数据 库 这 样 的 外 部 资源 
进行 读 写 操作 ， 在 高 并 发 的 情况 下 可 能 会 成 为 系统 的 瓶 项 。 既 然 如 此 ， 
我 们 很 容易 地 可 以 联想 到 ， 类 似 数据 访问 的 缓存 保护 是 否 也 可 以 应 用 到 
依赖 服务 的 调用 上 呢 ? 

答案 显而易见 ， 在 高 并 发 的 场景 之 下 ，Hystrix 中 提供 了 请 求 缓存 的 
功能 ， 我 们 可 以 方便 地 开局 和 使 用 请 求 缓 存 来 优化 系统 ， 达 到 减轻 高 并 
发 时 的 请 求 线程 消耗 、 降 低 请 求 啊 应 时 间 的 效果 。 











开启 请 求 缓存 功能 
Hystrix 请 求 缓存 的 使 用 非常 简单 ， 我 们 只 需要 在 实现 
HystrixCommand 或 HystrixObservableCommand 时 ， 通 过 重 载 


getCacheKey〈) 方法 来 开局 请 求 缓存 ， 比 如 : 

public class UserCommand extends HystrixCommand<User> { 

private RestTemplate restTemplate; 

private Long id; 

public UserCommand (RestTemplate restTemplate,Longid) { 

super (Setter.withGroupKey (HystrixCommandGroupKey.Factory.asKe 

this.restTemplate=restTemplate; 

this.id=id,; 

} 

(DOverride 

protected User run () { 

return restTemplate.getForObject ("http://USER- 
SERVICE/users/{1}",User.class,id) : 

} 

Override 

protected String getCacheKey () { 

return String.valueOf (id) ; 

} 


} 

在 上 面 的 例子 中 ， 我 们 通过 在 getCacheKey 方 法 中 返回 的 请 求 缓存 
key 值 〈 使 用 了 传 入 的 获取 User 对 象 的 id 值 ) ， 残 能 让 该 请 求 命令 具备 绥 
存 功 能 。 此 时 ， 当 不 同 的 外 部 请 求 处 理 逻 辑 调 用 了 同一 个 依赖 服务 时 ， 
Hystrix 会 根据 getCacheKey 方 法 返回 的 值 来 区 分 是 否 是 重复 的 请 求 ， 如 
果 它 们 的 cacheKey 相 同 ， 那 么 该 依赖 服务 只 会 在 第 一 个 请 求 到 达 时 被 真 
实地 调用 一 次 ， 另 外 一 个 请 求 则 是 直接 从 请 求 缓存 中 返回 结果 ， 所 以 通 
过 开启 请 求 绥 存 可 以 让 我 们 实现 的 Hystrix 命 令 具 备 下 面 几 项 好 处 : 

e 减 少 重复 的 请 求 数 ， 降 低 依赖 服务 的 并 发 度 。 

e 在 同一 用 户 请 求 的 上 下 文中 ， 相 同 依赖 服务 的 返回 数据 始终 保持 一 


致 。 

e 请 求 缓存 在 rn 〈《) 和 construct《) 执行 之 前 生效 ， 所 以 可 以 有 效 减 
少 不 必 要 的 线程 开销 。 

清理 失效 缓存 功能 

使 用 请 求 缓存 时 ， 如 果 只 是 读 操作 ， 那 么 不 需要 考虑 缓存 内 容 是 合 
正确 的 问题 ， 但 是 如 果 请 求 命 令 中 还 有 更 新 数据 的 写 操作 ， 那 么 缓存 中 
的 数据 就 需要 我 们 在 进行 写 操作 时 进行 及 时 处 理 ， 以 防止 读 操作 的 请 求 
命令 获取 到 了 失效 的 数据 。 

在 Hystrix 中 ， 我 们 可 以 通过 HystrixRequestCache.clear() 方法 来 进 
行 绥 存 的 清理 ， 具 体 示例 如 下 : 

public class UserGetCommand extends HystrixCommand<User> { 

private static final HystrixCommandKey 
GETTER_ KEY=HystrixCommandKey.Factory.asKey ("CommandKey") ; 

private RestTemplate restTemplate; 

private Long id; 

public UserGetCommand (RestTemplate restTemplate,Long id) { 

super (Setter.withGroupKey (HystrixCommandGroupKey.Factory.asKe 

.andCommandKey (GETTER_KEY) ) ; 

this.restTemplate=restTemplate; 

this.id=id,; 

} 

(DOverride 

protected User run () { 

return restTemplate.getForObject ("http://USER- 
SERVICE/users/{1}",User.class,id) : 

} 

(OOverride 











protected String getCacheKey () { 

/根据 id 置 入 缓存 

return String.valueOf (id) ; 

} 

public static void flushCache (Longid) { 

/刷新 缓存 ， 根 据 id 进 行 清理 

HystrixRequestCache.getInstance (GETTER_ KEY, 

HystrixConcurrencyStrategyDefault.getInstance () ) .clear (String.valt 

} 

} 

public class UserPostCommand extends HystrixCommand<User> { 

private RestTemplate restTemplate; 

private User user; 

public UserPostCommand (RestTemplate restTemplate,User user) { 

super (Setter.withGroupKey (HystrixCommandGroupKey.Factory.asKe 

this.restTemplate=restTemplate; 

this.user=user; 

} 

(OOverride 

protected User run () { 

// 写 操作 

User r=restTemplate.postForObject ("http://USER- 
SERVICE/users",user,User.class) : 

/刷新 缓存 ， 清 理 缓存 中 失效 的 User 

UserGetCommand.flushCache (user.getld () ) ; 





return r: 

} 

} 

该 示例 中 主要 有 两 个 请 求 命令 : UserGetCommand 用 于 根据 id 获取 
User 对 象 、 而 UserPostCommand 用 于 更 新 User 对 象 。 当 我 们 对 


UserGetCommand 命 令 实 现 了 请 求 缓存 之 后 ， 那 么 势必 需要 为 
UserPostCommand 命 令 实现 缓存 的 清理 ， 以 保证 User 被 更 新 之 后 ， 
Hystrix 请 求 绥 存 中 相同 缓存 Key 的 结果 被 移 除 ， 这 样 在 下 一 次 获取 User 
的 时 候 不 会 从 缓存 中 获取 到 未 更 新 的 结果 。 

我 们 可 以 看 到 ， 在 上 面 UserGetCommand 的 实现 中 ， 增 加 了 一 个 静态 
方法 flushCache， 该 方法 通过 
HystrixRequestCache.getInstance (GETTER_ KEY,HystrixConcurrencyStrat 








方法 从 默认 的 Hystrix 并 发 策略 中 根据 GETTER_KEY 获 取 到 该 命令 的 请 
求 缓存 对 象 HystrixRequestCache 的 实例 ， 然 后 再 调用 该 请 求 缓存 对 象 实 
例 的 dlear 方 法 ， 对 Key 为 更 新 User 的 id 值 的 缓存 内 容 进行 清理 。 而 在 
UserPostCommand 的 实现 中 ， 在 run 方法 调用 依赖 服务 之 后 ， 增 加 了 对 
UserGetCommand 中 静态 方法 flushCache 的 调用 ， 以 实现 对 失效 缓存 的 清 


理 。 

村: 作 ] 原 理 

通过 上 面 的 入 门 例子 ， 我 们 已 经 能 够 体会 到 在 Hystrix 中 实现 请 求 绥 
存 是 非常 方便 的 ， 那 么 它 是 如 何 做 到 的 呢 ? 我 们 不 妨 通过 分 析 其 源码 来 
了 解 一 下 它 的 实现 原理 ， 对 其 有 一 个 深入 的 理解 ， 有 助 于 指导 我 们 正确 
使 用 和 配置 请 求 缓存 。 由 于 getCacheKey 方法 在 AbstractCommand 抽 象 
命令 类 中 实现 ， 所 以 我 们 可 以 先 从 这 个 抽象 命令 类 的 实现 中 看 起 。 

从 下 面 AbstractCommand 的 源码 所 段 中 ， 我 们 可 以 看 到 ， 
getCacheKey 方 法 默认 返回 的 是 null， 并 且 从 isRequestCachingEnabled 方 
法 的 实现 逻辑 中 我 们 还 可 以 知道 ， 如 果 不 重 写 getCacheKey 方 法 ， 让 它 
返回 一 个 非 null 值 ， 那 么 绥 存 功能 是 不 会 开启 的 ; 同时 请 求 命令 的 缓存 
开局 属性 也 需要 设置 为 true 才 能 开局 《该 属性 默认 为 tue， 上 所 以 通 名 用 该 
属性 来 控制 请 求 缓存 功能 的 强制 关闭 ) 。 

abstract Class AbstractCommand<R> implements 
HystrixInvokableInfo<R>, 

HystrixObservable<R> { 





protected final HystrixRequestCache requestCache; 


protected String getCacheKey () { 
return null; 


} 

protected boolean isRequestCachingEnabled () { 

return properties.requestCacheEnabled () .get () && 
getCacheKey () !=null; 

} 


public Observable<R> toObservable () { 
// 尝 试 从 缓存 中 获取 结 


final boolean requestCacheEnabled=isRequestCachingEnabled (); 
final String cacheKey=getCacheKey 〈) ; 


final AbstractCommand<R> _cmd=this; 
if requestCacheEnabled) { 
HystrixCommandResponseFromCache<R> fromCache= 
(HystrixCommandResponseFromCache<R>) 
requestCache.get (cacheKey) ; 
if (fromCache !=null) { 
isResponseFromCache=true; 
return handleRequestCacheHitAndEmitValues (fromCache, cmd); 
} 
} 


Observable<R> hystrixObservable= 

Observable.defer (applyHystrixSemantics) .map (wrapWithAllOnNext 

Observable<R> afterCache; 

/加 入 缓存 

if (requestCacheEnabled && cacheKey !=null ) { 

HystrixCachedObservable<R> toCache= 

HystrixCachedObservable.from (hystrixObservable,this) ; 

HystrixCommandResponseFromCache<R> fromCache= 

(HystrixCommandResponseFromCache<R>) 

requestCache.putIfAbsent (cacheKey,toCache) ; 

if (fromCache !=null) { 

toCache.unsubscribe (); 

isResponseFromCache=true; 

return handleRequestCacheHitAndEmitValues (fromCache, cmd); 

} else { 

afterCache=toCache.toObservable (); 

} 

} else { 

afterCache=hystrixObservable; 

} 

} 


} 

另外 ， 从 命令 异步 执行 的 核心 方法 toObservable () 中 ， 我 们 可 以 看 
到 与 缓存 相关 的 主要 执行 步骤 ， 它 分 为 两 部 分 内 容 : 党 试 获 取 请 求 缓存 
以 及 将 请 求 结果 加 入 缓存。 








e。 符 试 获 取 请 求 缓存 : Hystrix ”命令 在 执行 前 会 根据 之 前 提 到 的 
isRequestCachingEnabled 方法 来 判断 当前 命令 是 否 启 用 了 请 求 缓存 。 如 
果 开 启 了 请 求 缓存 并 有 昌 重 写 了 getCacheKey 方 法 ， 并 返回 了 一 个 非 null 的 
缓存 Key 值 ， 那 么 就 使 用 getCacheKey 返回 的 ”Key 值 去 调用 
HystrixRequestCache 中 的 get (String cacheKey) 来 获取 绥 存 的 
HystrixCachedObservable 对 象 。 

e 将 请 求 结果 加 入 缓存 : ”在 执行 命令 缓存 操作 之 前 ， 我 们 可 以 看 到 
己 经 获得 了 一 个 延迟 执行 的 命令 结果 对 象 hystrixObservable。 接 下 来 与 
尝试 获取 请 求 缓存 操作 一 样 ， 需 要 先 判 断 当 前 命令 是 否 开启 了 请 求 绥 存 
功能 ， 如 果 开 局 了 请 求 缓 存 并 且 getCacheKey 返 回 了 有 具体 的 Key 值 ， 就 将 
hystrixObservable 对 象 包装 成 请 求 缓存 结果 HystrixCachedObservable 的 实 
例 对 象 toCache， 然 后 将 其 放 入 当前 命令 的 缓存 对 象 中 。 从 调用 的 方法 
putIfAbsent 中 ， 我 们 大 致 可 以 猜 到 在 请 求 缓存 对 象 HystrixRequestCache 
中 维护 了 一 个 线程 安全 的 Map 来 保存 请 求 缓存 的 响应 ， 所 以 在 调用 
putlfAbsent 将 包 疙 的 请 求 缓存 放 入 绥 存 对 象 后 ， 对 其 返回 结 
fromCache 进 行 了 判断 ， 如 果 其 不 为 null， 说 明 当 前 缓存 Key 的 请 求 命令 
缓存 命 中 ， 直 接 对 toCache 执 行 取消 订阅 操作 《〈 即 ， 不 再 发 起 真实 请 
求 ) ， 同 时 调用 缓存 命令 的 处 理 方 法 
handleRequestCacheHitAndEmitValues 来 执行 缓存 命中 的 结果 获取 。 如 果 
返回 的 ffromCache 为 null 说 明 缓存 没有 命中 ， 则 将 当前 结果 toCache 绥 存 
起 来 ， 并 将 其 转换 成 Observable 返 回 给 调用 者 使 用 。 

使 用 注解 实现 请 求 缓存 

Hystrix 的 请 求 缓存 除了 可 以 通过 上 面 传 统 的 方式 实现 之 外 ， 还 可 以 
通过 注解 的 方式 进行 配置 实现 。 注 解 配置 的 定义 实现 同 JSR 107 的 定义 
非常 相似 ， 但 由 于 Hystrix 不 需要 独立 外 置 的 缓存 系统 来 支持 ， 所 以 没有 
JSR 107 的 定义 那么 复杂 ， 它 只 提供 了 三 个 专用 于 请 求 缓存 的 注解 。 

注解 描述 属性 


@CacheResult | 该 注解 用 来 标记 请 求 命令 返回 的 结果 应 该 被 缓存 ， 它 必须 与 | cacheKeyMethod 





























@HystrixCommand 注解 结合 使 用 
@CacheRemove | 该 注解 用 来 让 请 求 命令 的 缓存 失效 ， 失 效 的 缓存 根据 定义 的 | commandKey， 


Key 决定 cacheKeyMethod 





@CacheKey 该 注解 用 来 在 请 求 命令 的 参数 上 标记 ， 使 其 作为 缓存 的 Key 
值 ， 如 果 没 有 标注 则 会 使 用 所 有 参数 。 如 果 同 时 还 使 用 了 


ecacheResult 和 ecacheRemove 注解 的 cacheKeyMethod 
方法 指定 缓存 Key 的 生成 ， 那 么 该 注解 将 不 会 起 作用 
JSR 107 是 Java 缓 存 API 的 定义 ， 也 被 称 为 JCache。 它 定义 了 一 系列 开 
发 人 员 使 用 的 标准 化 Java 绥 存 API 和 服务 提供 商 使 用 的 标准 SPI。 





下 面 我 们 从 几 个 方面 的 实例 来 看 看 这 几 个 注解 的 具体 使 用 方法 。 

e 设 置 请 求 缓存 : ”通过 注解 为 请 求 命 令 开 局 缓存 功能 非常 简单 ， 如 
下 例 所 示 ， 我 们 只 需 添 加 @CacheResult 注 解 即 可 。 当 该 依赖 服务 被 调用 
并 返回 User 对 象 时 ， 由 于 该 方法 被 @CacheResult 注 解 修 改 ， 所 以 Hystrix 
会 将 该 结果 置 入 请 求 缓存 中 ， 而 它 的 缓存 Key 值 会 使 用 所 有 的 参数 ， 也 
就 是 这 里 Long 类 型 的 id 值 。 





(OCacheResult 

@HystrixCommand 

public User getUserByld (Longid) { 

return restTemplate.getForObject ("http://USER- 
SERVICE/users/{1}",User.class,id) : 

} 


e 定 义 缓存 Key: ” 当 使 用 注解 来 定义 请 求 缓 存 时 ， 吞 要 为 请 求 命 令 指 
定 具 体 的 缓存 Key 生 成 规则 ， 我 们 可 以 使 用 @CacheResult 和 
@CacheRemove 注 解 的 cacheKeyMethod 方 法 来 指定 具体 的 生成 函数 ;也 
可 以 通过 使 用 @CacheKey 注 解 在 方法 参数 中 指定 用 于 组 装 绥 存 Key 的 元 

使 用 cacheKeyMethod 方法 的 示例 如 下 ， 它 通过 在 请 求 命 令 的 同一 个 
类 中 定义 一 个 专门 生成 Key 的 方法 ， 并 用 @CacheResult 注 解 的 
cacheKeyMethod 方 法 来 指定 它 即 可 。 它 的 配置 方式 类 似 于 
@HystrixCommand 服 务 降 级 fallbackMethod 的 使 用 。 

@CacheResult (cacheKeyMethod="getUserByIdCacheKey") 








@HystrixCommand 

public User getUserByld (Longid) { 

return restTemplate.getForObject ("http://USER- 
SERVICE/users/{1}",User.class,id) : 

} 

private Long getUserByldCacheKey (Longid) { 

return id; 


} 

通过 @CacheKey 注解 实现 的 方式 更 加 简单 ， 有 具体 示例 如 下 所 示 。 但 
是 在 使 用 @CacheKey 注 解 的 时 候 需 要 注意 ， 它 的 优先 级 比 
cacheKeyMethod 的 优先 级 低 ， 如 果 已 经 使 用 了 cacheKeyMethod 指 定 绥 存 
Key 的 生成 函数 ， 那 么 @CacheKey 注 解 不 会 生效 。 

(OCacheResult 

@HystrixCommand 

public User getUserByld (@CacheKey ("id") Longid) { 


return restTemplate.getForObject ("http:/USER-SERVICE/users/{1}", 

User.class,id) ; 

} 

@CacheKey 注解 除了 可 以 指定 方法 参数 作为 缓存 Key 之 外 ， 它 还 多 
许 访 问 参 数 对 象 的 内 部 属性 作为 缓存 Key。 比 如 下 面 的 例子 ， 它 指定 了 
User 对 象 的 id 属性 作为 缓存 Key。 


人 CacheResult 

@HystrixCommand 

public User getUserByld (@CacheKey ("id") User user) { 

return restTemplate.getForObject ("http://USER- 


SERVICE/users/{1}",User.class,user.getld () ) ; 


} 

e 绥 存 清理 : 在 之 前 的 例子 中 ， 我 们 已 经 通过 @CacheResult 注解 将 
请 求 结 果 置 入 Hystrix 的 请 求 缓存 之 中 。 知 该 内 容 调用 了 update 操 作 进 行 
了 更 新 ， 那 么 此 时 请 求 缓 存 中 的 结果 与 实际 结果 就 会 产生 不 一 致 ( 绥 存 
中 的 结果 实际 上 已 经 失效 了 ) ， 所 以 我 们 需要 在 update 类 型 的 操作 上 对 
失效 的 缓存 进行 清理 。 在 Hystrix 的 注解 配置 中 ， 可 以 通过 
Q@CacheRemove 注 解 来 实现 失效 缓存 的 清理 ， 比 如 下 面 的 例子 所 示 : 

(OCacheResult 














@HystrixCommand 

public User getUserByld (@CacheKey ("id") Longid) { 

return restTemplate.getForObject ("http://USER- 
SERVICE/users/{1}",User.class,id) : 

} 

@CacheRemove (commandKey="getUserByl1d") 

@HystrixCommand 

public void update (@CacheKey ("id") User user) { 

return restTemplate.postForObject ("http://USER- 


SERVICE/users",user,User.class) : 


需要 注意 的 是 ，@CacheRemove 注 解 的 commandKey 属 性 是 必须 要 指 
定 的 ， 它 用 来 指明 需要 使 用 请 求 缓存 的 请 求 合 令 ， 因 为 只 有 通过 该 属性 
的 配置 ，Hystrix 才 能 找到 正确 的 请 求 命 令 绥 存 位 置 。 


Des sw 
证 ~ is 





微服 务 染 构 中 的 依赖 通常 通过 远程 调用 实现 ， 而 远程 调用 中 最 常见 





的 问题 就 是 通信 消耗 与 连接 数 占 用 。 在 高 并 发 的 情况 之 下 ， 因 通信 次 数 
的 增加 ， 总 的 通信 时 间 消 耗 将 会 变 得 不 那么 理想 。 同 时 ， 因 为 依赖 服务 
的 线程 池 资 源 有 限 ， 将 出 现 排 队 等 竺 与 啊 应 延迟 的 情况 。 为 了 优化 这 两 
个 问题 ，Hystrix 提 供 了 HystrixCollapser 来 实现 请 求 的 合并 ， 以 减少 通信 
消耗 和 线程 数 的 占用 。 

HystrixCollapser 实现 了 在 HystrixCommand 之 前 放置 一 个 合并 处 理 
器 ， 将 处 于 一 个 很 短 的 时 间 窗 《默认 10 诸 秒 ) 内 对 同一 依赖 服务 的 多 个 
请 求 进行 整合 并 以 批量 方式 用 起 请 求 的 功能 《服务 提供 方 也 需要 提供 相 
应 的 批量 实现 接口 ) 。 通 过 HystrixCollapser 的 封装 ， 开 发 者 不 需要 关注 
线程 合并 的 细节 过 程 ， 只 需 关 注 批量 化 服务 和 处 理 。 下 面 我 们 从 
HystrixCollapser 的 使 用 实例 中 对 其 合并 请 求 的 过 程 一 探究 竟 。 

public abstract Class 
HystrixCollapser<BatchReturnType,ResponseType,RequestArgumentType> 
implements 

HystrixExecutable<ResponseType>,HystrixObservable<ResponseType> 








{ 


public abstract RequestArgumentType getRequestArgument (); 

protected abstract 
HystrixCommand<BatchReturnType>createCommand (Collection<Collapse 

protected abstract void mapResponseToRequests (BatchReturnType 
batchResponse,Collection<CollapsedRequest<ResponseType,RequestArgume 
requests) ; 


} 
A HystixC ollapseril 象 类 的 定义 中 可 以 看 到 ， 它 指定 了 三 个 不 同 的 
类 型 。 

eBatchReturnType: 合并 后 批量 请 求 的 返回 类 型 。 

eResponseType: 单个 请 求 返 回 的 类 型 。 

eRequestArgumentType: 请 求 参 数 类 型 。 

而 对 于 这 三 个 类 型 的 使 用 可 以 在 它 的 三 个 抽象 方法 中 看 到 。 

eRequestArgumentType getRequestArgument () : 该 函数 用 来 定义 获 
取 请 求 参数 的 方法 。 

eHystrixCommand<BatchReturnType>createCommand (Collection<Col 
requests) : 合并 请 求 产 生 批量 命令 的 具体 实现 方法 。 

emapResponseToRequests (BatchReturnType 
batchResponse,Collection<CollapsedRequest<ResponseType,RequestArgume 








reduests) : 批量 命令 结果 返回 后 的 处 理 ， 这 里 需要 实现 将 批量 结果 拆 
分 并 传递 给 合并 前 的 各 个 原子 请 求 命 令 的 逻辑 。 
接 下 来 ， 我 们 通过 一 个 简单 的 示例 来 直观 理解 实现 请 求 合 并 的 过 


王 。 
假设 当前 微服 务 USER-SERVICE 提 供 了 两 个 获取 User 的 接口 。 
e/users/{id}: 根据 id 返回 User 对 象 的 GET 请 求 接口 。 
e/users? ids={ids}: 根据 ids 返 回 User 对 象 列表 的 GET 请 求 接口 ， 其 中 

ids 为 以 逗号 分 隅 的 id 集合 。 

而 在 服务 消费 端 ， 已 经 为 这 两 个 远程 接口 通过 RestTemplate 实现 了 
简单 的 调用 ， 具 体 如 下 所 示 : 

(DService 

public class UserServiceImpl implements UserService { 

(OAutowired 

private RestTemplate restTemplate; 

(DOverride 

public User find (Longid) { 

return restTemplate.getForObject ("http://USER- 
SERVICE/users/{1}",User.class,id) : 

} 

(DOverride 

public List<User> findAll (List<Long> ids) { 

return restTemplate.getForObject ("http://USER-SERVICE/users? ids= 
{1}",List.class, StringUtils.join (ids,",") ) ; 

} 


} 
接 看 ， 我 们 实现 将 短 时 间 内 多 个 获取 单一 User 对 象 的 请 求 命 令 进 行 


e 第 一 步 ， 为 请 求 合 并 的 实现 准备 一 个 批量 请 求 命令 的 实现 ， 具 体 如 








区 
public Class UserBatchCommand extends 
HystrixCommand<List<User>> { 

UserService userService; 

List<Long> userlds; 

public © UserBatchCommand (UserService userService,List<Long> 
UserIds) { 

Super (Setter.withGroupKey (asKey ("userServiceCommand") ) ) ; 

this.userlds=userlds; 


this.userService=userService:; 

} 

(DOverride 

protected List<User> run () throws Exception { 
return userService.findAll (userlds) ; 


} 


} 

批量 请 求 命 令 实 际 上 就 是 一 个 简单 的 HystrixCommand 实现 ， 从 上 面 
的 实现 中 可 以 看 到 它 通过 调用 userService.findAll 方法 来 访问 /users? ids= 
{ids} 接 口 以 返回 User 的 列表 结果 。 

e 第 二 步 ， 通 过 继承 HystrixCollapser 实 现 请 求 合 并 器 : 

public class UserCollapseCommand extends 
HystrixCollapser<List<User>,User,Long> { 

private UserService userService; 

private Long userld; 

public UserCollapseCommand (UserService userService,Long userld) { 

super (Setter.withCollapserKey (HystrixCollapserKey.Factory.asKey 

("userCollapseCommand") ) .andCollapserPropertiesDefaults ( 

HystrixCollapserProperties.Setter () .withTimerDelayInMilliseconds (1 

this.userService=userService; 

this.userld=userld; 

} 

(DOverride 

public Long getRequestArgument () { 

return UserId; 

} 

(DOverride 

protected HystrixCommand<List<User>> 

createCommand (Collection<CollapsedRequest<User,Long>> 
collapsedRequests) { 

List<Long> userlds=new ArrayList<> (collapsedRequests.size () ) ; 

userlds.addAll (collapsedRequests.stream () .map (CollapsedRequest: 

t (Collectors.toList () ) ) ; 

return new UserBatchCommand (userService,userlds) ; 

} 

(DOverride 

protected void mapResponseToReduests (List<User> batchResponse, 





Collection<CollapsedRequest<User,Long>> collapsedRequests) { 

int count=0; 

for (CollapsedRequest<User,Long> collapsedRequest 
collapsedRequests) { 

User User=batchResponse.get (count++); 

collapsedRequest.setResponse (user) ; 

} 

} 


} 

在 上 面 的 构造 函数 中 ， 我 们 为 请 求 合 并 器 设置 了 时 间 延 人 运 属 性 ， 合 
并 器 会 在 该 时 间 窗 内 收集 获取 单个 User 的 请 求 并 在 时 间 窗 结束 时 进行 
合并 组 装 成 单个 批量 请 求 。getRequestArgument 方 法 返回 给 定 的 单个 请 
求 参 数 userId， 而 createCommand 和 mapResponseToRequests 是 请 求 合 并 
器 的 两 个 核心 。 

ecreateCommand: 该 方法 的 collapsedRequests 参 数 中 保存 了 延迟 时 间 
窗 中 收集 到 的 所 有 获取 单个 User 的 请 求 。 通 过 获取 这 些 请 求 的 参数 来 组 
织 上 面 我 们 准备 的 批量 请 求 命令 UserBatchCommand 实 例 。 

emapResponseToRequests: 在 批量 请 求 命令 UserBatchCommand 实 
例 被 触发 执行 完成 之 后 ， 访 方法 开始 执行 ， 其 中 batchResponse 参数 保 
存 了 createCommand 中 组 织 的 批量 请 求 命令 的 返回 结果 ， 而 
collapsedRequests 参 数 则 代表 了 每 个 被 合并 的 请 求 。 在 这 里 我 们 通过 过 
历 批 量 结果 batchResponse 对 象 ， 为 collapsedRequests 中 每 个 合并 前 的 单 
个 请 求 设 置 返回 结果 ， 以 此 完成 批量 结果 到 单个 请 求 结 果 的 转换 。 

下 图 展示 了 在 未 使 用 HystrixCollapser 请 求 合 并 器 之 前 的 线程 使 用 情 
况 。 可 以 看 到 ， 当 服务 消费 者 同时 对 USER-SERVICE 的 /users/{id} 接 口 
发 起 了 5 个 请 求 时 ， 会 回访 依赖 服务 的 独立 线程 池 中 申请 5 个 线程 来 完成 
各 目的 请 求 操 作 。 























而 在 使 用 了 HystrixCollapser 请 求 合并 器 之 后 ， 相 同情 况 下 的 线程 占 
用 如 下 图 所 示 。 由 于 同一 时 间 发 生 的 5 个 请 求 处 于 请 求 合并 器 的 一 个 时 
间 窗 内 ， 这 些 发 向 /users/{id} 接 口 的 请 求 被 请 求 合 并 器 拦截 下 来 ， 并 在 
合并 器 中 进行 组 合 ， 然 后 将 这 些 请 求 合并 成 一 个 请 求 发 向 USER- 
SERVICE 的 批量 接口 /nsers? ids={fids}。 在 获取 到 批量 请 求 结果 之 后 ， 通 
过 请 求 合并 器 再 将 批量 结果 拆 分 并 分 配给 每 个 被 合并 的 请 求 。 从 图 中 我 
们 可 以 看 到 ， 通 过 使 用 请 求 合 并 器 有 效 减少 了 对 线程 池 中 资源 的 占用 。 
所 以 在 资源 有 效 并 且 短 时 间 内 会 产生 高 并 发 请 求 的 时 候 ， 为 避免 连接 不 
够 用 而 引起 的 延迟 可 以 考虑 使 用 请 求 合 并 器 的 方式 来 处 理 和 优化 。 
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使 用 注解 实现 请 求 合 并 器 

在 快速 入 门 的 例子 中 ， 我 们 使 用 @HystrixCommand 注 解 优雅 地 实现 
了 HystrixCommand 的 定义 ， 那 么 对 于 请 求 合并 器 是 否 也 可 以 通过 注解 来 
定义 呢 ? 答 案 是 肯定 的 ! 

以 上 面 实 现 的 请 求 合 并 器 为 例 ， 还 可 以 通过 如 下 方式 实现 : 





(DService 

public class UserService { 

(OAutowired 

private RestTemplate restTemplate; 

@HystrixCollapser (batchMethod="findAll",collapserProperties={ 

@HystrixProperty (name="timerDelayInMilliseconds",value="100") 

? 

public User find (Longid) { 

return null; 

} 

@HystrixCommand 

public List<User> findAll (List<Long> ids) { 

return restTemplate.getForObject ("http://USER-SERVICE/users? ids= 
{1}",List.class, StringUtils.join (ids,",") ) ; 

} 


} 

我 们 之 前 已 经 介绍 过 @HystrixCommand 了 ， 可 以 看 到 ， 这 里 通过 它 
定义 了 两 个 Hystrix 命 令 ， 一 个 用 于 请 求 /users/{id} 接 口 ， 一 个 用 于 请 
求 /users? ids={ids} 接 口 。 而 在 请 求 /users/{id} 接 口 的 方法 上 通过 
@HystrixCollapser 注 解 为 其 创建 了 合并 请 求 器 ， 通 过 batchMethod 属性 
站 定 了 批量 请 求 的 实现 方法 为 findAll 方法 ( 即 请 求 /users? ids={ids} 接 口 
的 命令 ) ， 同 时 通过 collapserProperties 属 性 为 合并 请 求 器 设置 了 相关 属 
性 ， 这 里 使 用 
@HystrixProperty (name="timerDelayInMilliseconds",value="100") 将 合 
并 时 间 窗 设置 为 100 蝇 秒 。 这 样 通 过 @HystrixzCollapser 注 解 简单 而 又 优 
雅 地 实现 了 在 /users/{fid} 依 赖 服务 之 前 设置 了 一 个 批量 请 求 合 并 器 。 

请 求 合 并 的 额外 开销 

虽然 通过 请 求 合 并 可 以 减少 请 求 的 数量 以 绥 解 依赖 服务 线程 池 的 资 
源 ， 但 是 在 使 用 的 时 候 也 需要 注意 它 所 带 来 的 额外 开销 : 用 于 请 求 合 并 
的 延迟 时 间 窗 会 使 得 依赖 服务 的 请 求 延 人 运 增高 。 比 如 ， 某 个 请 求 不 通过 
请 求 合 并 器 访问 的 平均 耗 时 为 5ms， 请 求 合 并 的 延迟 时 间 窗 为 10ms〔 默 
认 值 ) ， 那 么 当 该 请 求 设置 了 请 求 合 并 器 之 后 ， 最 坏 情况 下 《在 延迟 时 
间 窗 结束 时 才 发 起 请 求 ) 该 请 求 需要 15ms 才 能 完成 。 

由 于 请 求 合并 器 的 延迟 时 间 窗 会 珊 来 额外 开销 ， 所 以 我 们 是 否 使 用 
主要 考虑 下 面 两 
上 方面 。 

e 请 求 命令 本 和 映 的 延 人 运 ”。 如 果 依 赖 服务 的 请 求 命令 本 里 是 一 个 高 延 























述 的 命令 ， 那 么 可 以 使 用 请 求 合 并 右 ， 因 为 延迟 时 间 窗 的 时 间 消 耗 显 得 
微不足道 了 。 

e 延 迟 时 间 窗 内 的 并 发 量 ”。 如 果 一 个 时 间 窗 内 只 有 1 一 2 个 请 求 ， 那 
么 这 样 的 依赖 服务 不 适合 使 用 请 求 合 并 硕 。 这 种 情况 不 但 不 能 提升 系统 
性 能 ， 反 而 会 成 为 系统 上 瓶颈 ， 因 为 每 个 请 求 都 需要 多 消耗 一 个 时 间 窗 才 
啊 应 。 相 反 ， 如 末 一 个 时 间 窗 内 具有 很 高 的 并 发 量 ， 并 且 服 务 提 供 方 也 
实现 了 批量 处 理 接 口 ， 那 么 使 用 请 求 合并 需 可 以 有 效 减少 网 络 连接 数量 
并 极 大 提升 系统 吞吐 量 ， 此 时 延迟 时 间 窗 所 增加 的 消耗 就 可 以 忽略 不 计 
了 。 








在 之 前 介绍 Hystrix 的 使 用 方法 时 ， 已 经 涉及 过 一 些 Hystrix 属 性 的 配 
是 ， 我 人 ] 可 以 根据 实现 HystrixCommand 的 不 同方 式 将 配置 方法 分 为 如 下 
两 类 。 

e 当 通过 继承 的 方式 实现 时 ， 可 使 用 Setter 对 象 来 对 请 求 命令 的 属性 
进行 设置 ， 比 如 下 面 的 例子 : 

public HystrixCommandInstance (intid) { 

super (Setter.withGroupKey (HystrixCommandGroupKey.Factory.asKe 

.andCommandPropertiesDefaults (HystrixCommandProperties.Setter () 

.withExecutionTimeoutInMilliseconds (500) ) ) ; 

this.id=id; 








} 

e 当 通过 注解 的 方法 实现 时 ， 只 需 使 用 @HystrixCommand 中 的 
commandProperties 属 性 来 设置 ， 比 如 : 

@HystrixCommand (commandKey="helloKey", 

commandProperties={ 

@HystrixProperty (name="execution.isolation.thread.timeoutInMilliseco 


1 

) 

public User getUserByld (Longid) { 

return restTemplate.getForObject ("http://USER- 
SERVICE/users/{1}",User.class,id) : 

} 





实际 上 ，Hystrix 为 我 们 提供 的 配置 内 容 和 配置 方式 远 不 止 上 面 这 
些 ， 它 提供 了 非常 丰富 和 灵活 的 配置 方法 ， 下 面 我 们 将 详解 介绍 
HystrixPropertiesStrategy 实 现 的 各 项 配置 属性 。 在 具体 说 明 这 些 属性 之 

前 ， 我 们 需要 了 人 解 一 下 这 些 属性 都 存在 下 面 4 个 不 同 优先 级 别 的 配置 
《优先 级 由 低 到 高 〉。 

e 全 局 默认 值 : 如 果 没 有 设置 下 面 三 个 级 别 的 属性 ， 那么 这 个 属性 
就 是 默认 值 。 由 于 该 属性 通过 代码 定义 ， 所 以 对 于 这 个 级 别 ， 我 们 主要 
关注 它 在 代码 中 定义 的 默认 值 即 可 。 

e 全 局 配置 属性 : ”通过 在 配置 文件 中 定义 全 局 属性 值 ， 在 应 用 启动 
oo 与 Spring Cloud Config 和 Spring Cloud Bus 实 现 的 动态 刷新 配置 功 

E 配 合 下 ， 可 以 实现 对 “全 局 默认 值 ” 的 履 盖 以 及 在 运行 期 对 “全 局 默认 
舍 ” 的 动态 调整 。 














e 实 例 默认 值 : ”通过 代码 为 实例 定义 的 默认 值 。 通 过 代码 的 方式 为 
实例 设置 属性 值 来 覆 兰 默认 的 全 局 配置 。 

e 实 例 配置 属性 : ”通过 配置 文件 来 为 指定 的 实例 进行 属性 配置 ， 以 
履 盖 前 面 的 三 个 默认 值 。 它 也 可 用 Spring Cloud Config 和 Spring Cloud 
Bus 实 现 的 动态 刷新 配置 功能 实现 对 具体 实例 配置 的 动态 调整 。 

通过 理解 Hystrix 4 个 级 别 的 属性 配置 ， 对 设置 Hystrix 的 默认 值 以 及 
在 线 上 如 何 根 据 实际 情况 去 调整 配置 非常 有 帮助 ， 下 面 我 们 来 具体 看 看 
它 有 哪些 具体 的 属性 配置 。 

















Command 属 性 


Command 属 性 主要 用 来 控制 HystrixCommand 命 令 的 行为 。 

它 主 要 有 下 面 5 种 不 同类 型 的 属性 配置 。 

execution 配 置 

execution 配 置 控制 的 是 HystrixCommand.run 〈) 的 执行 。 

eexecution.isolation.strategy: 该 属性 用 来 设置 
HystrixCommand.run《〈) 执行 的 隔离 策略 ， 它 有 如 下 两 个 选项 。 

@THREAD: 通过 线程 池 隔 离 的 策略 。 它 在 独立 的 线程 上 执行 ， 并 且 
它 的 并 发 限制 受 线程 池 中 线程 数量 的 限制 。 

SEMAPHORE: 通过 信号 量 隔离 的 策略 。 它 在 调用 线程 上 执行 ， 并 
且 它 的 并 发 眼 制 受信 号 量 计 牧 限制 。 


全 局 默认 值 THREAD 

















全 局 配置 属性 | hystrix.command.default.execution.isolation.strategy 


实例 默认 值 通过 HystrixCommandProperties.Setter() .withExecutionIsolationStrategy 
(ExecutionIsolationStrategy.THREAD) 设置, 也 可 通过 @HystrixProperty 


(name="execution.isolation.strategy",，value= "THREAD") 注解 设置 





实例 配置 属性 | hystrix.command.HystrixCommandKey.execution.isolation.strategy 





eexecution.isolation.thread.timeoutInMilliseconds: 该 属性 用 来 配置 
HystrixCommand 执 行 的 超时 时 间 ， 单 位 为 室 秒 。 当 HystrixCommand 执 
行 时 间 超 过 该 配置 值 之 后 ，Hystrix 会 将 该 执行 命令 标记 为 TIMEOUT 并 
进入 服务 降级 处 理 逻 辑 。 


属性 级 别 默认 值 、 配 置 方式 、 配 置 属性 





全 局 默认 值 1000 毫秒 


续 表 


属性 级 别 默认 值 、 配 置 方式 、 配 置 属性 


全 局 配置 属性 | hystrix.command.default.execution.isolation.thread.timeoutIn- 


Milliseconds 


实例 默认 值 通过 HystrixCommandProperties.Setter() .withExecutionTimeoutIn- 


Milliseconds (int value) 设置 ， 也 可 通过 @HystrixProperty (name= 
"execution.isolation.thread.timeoutInMilliseconds",value="2000") 
注解 来 设置 

实例 配置 属性 | hystrix.command.HystrixCommandKey.execution.isolation.thread. 


timeoutInMilliseconds 


eexecution.timeout.enabled: 该 属性 用 来 配置 
HystrixCommand.run〈) 的 执行 是 人 否 局 用 超时 时 间 。 默 认为 tue， 如 果 
设置 为 false， 那 么 execution.isolation.thread.timeoutInMilliseconds 属 性 的 


配置 将 不 再 起 作用 。 


属性 级 别 默认 值 、 配 置 方式 、 配 置 属 性 
全 局 炭 认 值 
全 局 配置 属性 


实例 默认 值 通过 HystrixCommandProperties.Setter() .withExecutionTimeout- 
Enabled(boolean value) 设置 ， 也 可 通过 @HystrixProperty (name= 


"execution.timeout.enabled"，value="false") 注 解 来 设置 


实例 配置 属性 hystrix.command.HystrixCommandKey.execution.timeout.enabled 


eexecution.isolation.thread.interruptOnTimeout: 该 属性 用 来 配置 当 
HystrixCommand.run 〈) 执行 超时 的 时 候 是 否 要 将 它 中 断 。 


属性 级 别 默认 值 、 配 置 方 式 、 配 置 属 性 
全 局 默认 什 


全 局 配置 属性 | hystrix.command.default.execution.isolation.thread. 
interruptonTimeout 


实例 默认 值 通过 HystrixCommandProperties.Setter() .withExecutionIsolation- 








ThreadInterruptOonTimeout (boolean value) 设置 ， 也 可 通过 @Hystrix- 


Property (name="execution.isolation.thread.interruptonTimeout", 
value="false") 注解 来 设置 
实例 配置 属性 hystrix.command.HystrixCommandKey.execution.isolation.thread. 


interruptOonTimeout 


eexecution.isolation.thread.interruptOnCancel: 该 属性 用 来 配置 当 
HystrixCommand.run 〈) 执行 被 取消 的 时 候 是 否 要 将 它 中 断 。 





= 配置 方式 、 配 置 属性 


和 aa command .default.execution.isolation.thread . 
interruptOnCancel 


实例 默认 值 通过 HystrixCommandProperties .Setter() .withExecutionIsolation- 


ThreadInterruptOnCancel (boolean value) 设置， 也 可 通过 @Hystrix- 
Property (name="execution.isolation.thread.interruptOnCancel", 
value="false") 注解 来 设置 


实例 配置 属性 ”| hystrix.command.HystrixCommandKey .execution.isolation.thread. 
interruptonCancel 


eexecution.isolation.semaphore.maxConcurrentRequests: 当 
HystrixCommand 的 隔离 策略 使 用 信号 量 的 时 候 ， 该 属性 用 来 配置 信号 量 
的 大 小 《并 发 请 求 数 ) 。 当 最 大 并 发 请 求 数 达 到 该 设置 值 时 ， 后 续 的 请 
ee 3 


全 局 默认 值 


全 局 配置 属性 天 汪汪 command.default .execution.isolation.semaphore . 
maxConcurrentRequests 


实例 默认 值 通过 HystrixCommandProperties.Setter() .withExecutionIsolation- 











SemaphoreMaxConcurrentRequests (int value) 设置 ， 也 可 通 是 过 6GHYystrix- 


Property (name="execution.isolation.semaphore.maxConcurrentRe 


quests"，value="2") 注 解 来 设置 


实例 配置 属性 hystrix.command.HystrixCommandKey .execution.isolation.semaphore. 
maxConcurrentRequests 


fallback 配 置 

下 面 这 些 属性 用 来 控制 HystrixCommand.getFallback() 的 执行 。 这 
些 属性 同时 适用 于 线程 池 的 信号 量 的 隔离 策略 。 

efallback.isolation.semaphore.maxConcurrentRequests: 该 属性 用 来 设 
置 从 调用 线程 中 允许 HystrixCommand. getFallback () 方法 执行 的 最 大 并 
发 请 求 数 。 当 达 到 最 大 并 发 请 求 数 时 ， 后 续 的 请 求 将 会 被 拒绝 并 抛 出 异 

和 常 〈 因 为 它 已 经 没有 后 续 的 fallback 可 以 被 调用 了 ) 。 











属性 级 别 默认 值 、 配 置 方式 、 配 置 属 性 
全 局 默认 什 


全 局 配置 属性 hystrix.command.default.fallback.isolation.semaphore. 
maxConcurrentRequests 


实例 默认 值 通过 HystrixCommandProperties.Setter() .withFallbackIsolation- 


SemaphoreMaxConcurrentRequests (int value) 设置 , 也 可 通过 @HystrixProperty 


(name="fallback.isolation.semaphore.maxConcurrentRequests", 
value="20") 注解 来 设置 


实例 配置 属性 ”| hystrix.command.HystrixCommandKey.fallback.isolation.semaphore. 
maxConcurrentRequests 


efallback.enabled: 该 属性 用 来 设置 服务 降级 策略 是否 局 用， 如 来 设 
置 为 false， 那 么 当 请 求 失败 或 者 拒绝 发 生 时 ， 将 不 会 调用 
HystrixCommand.getFallback ( ) 来 执行 服务 降级 逻辑 。 


属性 级 别 默认 值 、 配 置 方式 、 配 置 属性 
全 局 BKA 
全 局 配置 届 全 





实例 默认 值 通 过 HystrixCommandProperties.Setter() .withFallbackEnabled 
(boolean value) 设置 ， 也 可 通过 @HystrixProperty (name= "fallback. 
enabled"，value="false") 注解 来 设置 


实例 配置 属性 ”| 配置 属性 : hystrix.command.HystrixCommandKey.fallback.enabled 
circuitBreaker 配 置 
下 面 这 些 是 断路 器 的 属性 配置 ， 用 来 控制 HystrixCircuitBreaker 的 行 





ecircuitBreaker.enabled: 该 属性 用 来 确定 当 服 务 请 求 命令 失败 时 ， 是 
否 使 用 断路 喜来 跟踪 其 健康 指标 和 熔断 请 求 。 


全 局 默认 值 
全 局 配置 属性 hystrix.command.default.circuitBreaker.enabled 


实例 默认 值 通过 HystrixCommandProperties.Setter() .withCircuitBreakerEnabled 





ecircuitBreaker.requestVolumeThreshold: 该 属性 用 来 设置 在 滚动 时 
间 窗 中 ， 上 断路 器 熔断 的 最 小 请 求 数 。 例 如 ， 默 认 该 值 为 20 的 时 候 ， 如 果 
滚动 时 间 窗 〈 默 认 10 秒 ) 内 仅 收 到 了 19 个 请 求 ， 即 使 这 19 个 请 求 都 失败 
了 ， 断 路 器 也 不 会 打开 。 


ecircuitBreaker.sleepWindowInMilliseconds: 该 属性 用 来 设置 当 上 断路 
响 打 开 之 后 的 休眠 时 间 窗 。 休 眠 时 间 窗 结束 之 后 ， 会 将 断路 右 置 为 “ 半 
开 ” 状 态 ， 洽 试 熔断 的 请 求 合 令 ， 如 有 果 依 然 失 败 就 将 断路 右 继 续 设 置 
为 “打开 ?状态 ， 如 果 成 功 就 设置 为 “关闭 ?状态 。 


ecircuitBreaker.errorThresholdPercentage: 该 属性 用 来 设置 断路 器 打 
开 的 错误 百分比 条 件 。 例 如 ， 默 认 值 为 5000 的 情况 下 ， 表 示 在 滚动 时 间 
窗 中 ， 在 请 求 数量 超过 circuitBreaker.requestVolumeThreshold 闵 值 的 前 
提 下 ， 如 果 错 误 请 求 数 的 百分比 超过 50， 束 把 断路 器 设置 为 “打开 ” 状 
态 ， 人 否则 就 设置 为 “关闭 ”状态 。 


续 表 
ecircuitBreaker.forceOpen: 如 果 将 该 属性 设置 为 tue， 断 路 器 将 强制 


进入 “打开 ”状态 ， 它 会 拒绝 所 有 请 求 。 该 属性 优先 于 
circuitBreaker.forceClosed 属 性 。 











ecircuitBreaker.forceClosed: 如 果 将 该 属性 设置 为 tue， 断 路 器 将 强 
制 进 入 “关闭 ”状态 ， 它 会 接收 所 有 请 求 。 如 果 circuitBreaker.forceOpen 属 
性 为 tue， 访 属性 不 会 生效 。 


metrics 配 置 

下 面 的 属性 均 与 HystrixCommand 和 HystrixObservableCommand 执 行 
中 捕获 的 指标 信息 有 关 。 

emetrics.rollingStats.timeInMilliseconds: 该 属性 用 来 设置 滚动 时 间 窗 
的 长 度 ， 单 位 为 野 秒 。 该 时 间 用 于 断路 器 判断 健康 度 时 需要 收集 信息 的 
持续 时 间 。 断 路 器 在 收集 指标 信息 的 时 候 会 根据 设置 的 时 间 窗 长 度 拆 分 
成 多 个 “ 桶 ?来 累计 各 度量 值 ， 每 个 “ 棚 ?” 记 录 了 一 段 时 间 内 的 采集 指标 。 
例如 ， 当 采用 默认 值 10000 坚 秒 时 ， 断 路 器 默认 将 其 拆 分 成 10 个 桶 “〈 桶 
的 数量 也 可 通过 ”metrics.rollingStats.numBuckets 参 数 设 置 ) ， 每 个 桶 记 
录 1000 坚 秒 内 的 指标 信息 。 


注意 : 该 属性 从 Hystrix ”1.4.12 版 本 开始 (Brixton.SR5 版 本 中 使 用 了 
1.5.3 版 本 ) ， 只 有 在 应 用 初始 化 的 时 候 生 效 ， 通 过 动态 刷新 配置 不 会 产 
生效 果 ， 这 样 做 是 为 了 避免 出 现 运行 期 监测 数据 丢失 的 情况 。 

emetrics.rollingStats.numBuckets: 该 属性 用 来 设置 滚动 时 间 窗 统计 指 
标 信息 时 划分 “ 桶 ”的 数量 。 











注意 : metrics.rollingStats.timeInMilliseconds 参数 的 设置 必须 能 够 被 
metrics.rollingStats.numBuckets 参 数 整除 ， 不 然 将 抛 出 异常 。 该 参数 与 
metrics.rollingStats.timeInMilliseconds 一 样 ， 从 Hystrix 1.4.12 版 本 开始 

(Brixton.SR5 版 本 中 使 用 了 1.5.3 版 本 )〉 ， 只 有 在 应 用 初始 化 的 时 候 生 
效 ， 通 过 动态 刷新 配置 不 会 产生 效果 ， 这 样 做 是 为 了 避免 出 现 运行 期 监 
测 数据 丢失 的 情况 。 

emetrics.rollingPercentile.enabled: 该 属性 用 来 设置 对 命令 执行 的 延 
述 是 否 使 用 百 分 位 数 来 跟踪 和 计算 。 如 果 设 置 为 false， 那 么 所 有 的 概要 
统计 部 将 返回 -1。 


emetrics.rollingPercentile.timeInMilliseconds: 该 属性 用 来 设置 百 分 位 
统计 的 滚动 窗口 的 持续 时 间 ， 单 位 为 坚 秒 。 


注意 : 该 属性 从 Hystrix 1.4.12 版 本 开始 (Brixton.SR5 版 本 中 使 用 了 
1.5.3 版 本 ) ， 只 有 在 应 用 初始 化 的 时 候 生 效 ， 通 过 动态 刷新 配置 不 会 产 
生效 果 ， 这 样 做 是 为 了 避免 出 现 运行 期 监测 数据 丢失 的 情况 。 

emetrics.rollingPercentile.numBuckets: 该 属性 用 来 设置 百 分 位 统计 
滚动 窗口 中 使 用 “ 桶 ?的 数量 。 


注意 : metrics.rollingPercentile.timeInMilliseconds 参数 的 设置 必须 能 
够 被 metrics.rollingPercentile.numBuckets 参 数 整除 ， 不 然 将 会 抛 出 异常 。 
该 属性 从 Hystrix 1.4.12 版 本 开始 (Brixton.SR5 版 本 中 使 用 了 1.5.3 版 
本 ) ， 只 有 在 应 用 初始 化 的 时 候 生 效 ， 通 过 动态 刷新 配置 不 会 产生 效 
果 ， 这 样 做 是 为 了 避免 出 现 运行 期 监测 数据 丢失 的 情况 。 

emetrics.rollingPercentile.bucketSize: 该 属性 用 来 设置 在 执行 过 程 中 
每 个 “ 桶 ”中 保留 的 最 大 执行 次 数 。 如 果 在 滚动 时 间 窗 内 发 生 超过 该 设 定 
值 的 执行 次 数 ， 就 从 最 初 的 位 置 开 始 重 写 。 例 如 ， 将 该 值 设置 为 100， 
深 动 窗口 为 10 秒 ， 帮 在 10 秒 内 一 个 “ 桶 ?中 发 生 了 500 次 执行 ， 那 么 
该 “ 桶 ”中 只 保留 最 后 的 100 次 执行 的 统计 。 男 外 ， 增 加 该 值 的 大 小 将 会 
增加 内 存量 的 消耗 ， 并 增加 排序 百 分 位 数 所 需 的 计算 时 间 。 


续 表 


注意 : 该 属性 从 Hystrix 1.4.12 版 本 开始 (Brixton.SR5 版 本 中 使 用 了 
1.5.3 版 本 ) ， 只 有 在 应 用 初始 化 的 时 候 生 效 ， 通 过 动态 刷新 配置 不 会 产 
生效 果 ， 这 样 做 是 为 了 避免 出 现 运行 期 监测 数据 丢失 的 情况 。 

emetrics.healthSnapshot.intervalInMilliseconds: 该 属性 用 来 设置 采集 
影响 断路 器 状态 的 健康 快照 〈 请 求 的 成 功 、 错 误 和 百分比) 的 间隔 等 待 时 











间 。 


requestContext 配 置 
下 面 这 些 属性 涉及 HystrixCommand 使 用 的 HystrixRequestContext 的 设 
置 








| erequestCache.enabled: 此 属性 用 来 配置 是 否 开局 请 求 绥 存 。 


erequestLog.enabled: 该 属性 用 来 设置 HystrixCommand 的 执行 和 事 
件 是 否 打 印 日 志 到 HystrixRequestLog 中 。 


collapser 属 性 


该 属性 除了 在 代码 中 用 set 和 配置 文件 配置 之 外 ， 也 可 使 用 注解 进行 
配置 。 可 使 用 @HystrixCollapser 中 的 collapserProperties 属 性 来 设置 ， 比 
如 : 

@HystrixCollapser (batchMethod="batch",collapserProperties={ 

@HystrixProperty (name="timerDelayInMilliseconds",value="20") 


}> 

下 面 这 些 属性 用 来 控制 命令 合并 相关 的 行为 。 

emaxRequestsInBatch: 该 参数 用 来 设置 一 次 请 求 合并 批 处 理 中 允许 
的 最 大 请 求 数 。 


etimerDelayInMilliseconds: 该 参数 用 来 设置 批 处 理 过 程 中 每 个 命令 
延迟 的 时 间 ， 单 位 为 又 秒 。 


erequestCache.enabled: 该 参数 用 来 设置 批 处 理 过 程 中 是 人 否 开局 请 求 
绥 存 O 








threadPool 必 性 


该 属性 除了 在 代码 中 用 set 和 配置 文件 配置 之 外 ， 还 可 使 用 注解 进行 
配置 。 可 使 用 @HystrixCommand 中 的 threadPoolProperties 属 性 来 设置 ， 
比如 : 

@HystrixCommand (fallbackMethod="helloFallback",commandKey="h' 

threadPoolProperties={ 

@HystrixProperty (name="coreSize",value="20") 


} 


) 

下 面 这 些 属性 用 来 控制 Hystrix 命 令 所 属 线程 池 的 配置 。 

ecoreSize: 该 参数 用 来 设置 执行 命令 线程 池 的 核心 线程 数 ， 该 值 也 
就 是 命令 执行 的 最 大 并 发 量 。 


emaxQueueSize: 该 参数 用 来 设置 线程 池 的 最 大 队列 大 小 。 当 设置 
为 -1 时 ， 线 程 池 将 使 用 SynchronousQueue 实 现 的 队列 ， 人 否则 将 使 用 
LinkedBlockingQueue 实 现 的 队列 。 


续 表 


注意 : 该 属性 只 有 在 初始 化 的 时 候 才 有 用 ， 无 法 通过 动态 刷新 的 方 
式 来 调整 。 

equeueSizeRejectionThreshold: 该 参数 用 来 为 队列 设置 拒绝 闵 值 。 通 
过 该 参数 ， 即 使 队列 没有 达到 最 大 值 也 能 拒绝 请 求 。 该 参数 主要 是 对 
LinkedBlockingQueue 队 列 的 补 序 ， 因 为 LinkedBlockingQueue 队 列 不 能 
动态 修改 它 的 对 象 大 小 ， 而 通过 该 属性 束 可 以 调整 拒绝 请 求 的 队列 大 小 
3 





注意 : 当 maxQueueSize 属 性 为 -1 的 时 候 ， 该 属性 不 会 生效 。 

emetrics.rollingStats.timeInMilliseconds: 该 参数 用 来 设置 滚动 时 间 窗 
的 长 度 ， 单 位 为 蝇 秒 。 该 滚动 时 间 窗 的 长 度 用 于 线程 池 的 指标 度量 ， 它 
会 被 分 成 多 个 “ 桶 ?来 统计 指标 。 


续 表 


emetrics.rollingStats.numBuckets: 该 参数 用 来 设置 滚动 时 间 窗 被 划分 
成 “ 桶 ”的 数量 。 


注意 : metrics.rollingStats.timeInMilliseconds 参数 的 设置 必须 能 够 被 
metrics.rolling-Stats.numBuckets 参 数 整 除 ， 不 然 将 会 抛 出 异常 。 





Hyvystrixf» 





在 断路 占 原 理 的 介绍 中 ， 我 们 多 次 提 到 关于 请 求 命令 的 度量 指标 的 
判断 。 这 些 度量 指 标 者 是 HystrixCommand 和 HystrixObservableCommand 
实例 在 执行 过 程 中 记录 的 重要 信息 ， 它 们 除了 在 Hystrix 汤 路 器 实现 中 使 
用 之 外 ， 对 于 系统 运 维 也 有 非常 大 的 帮助 。 这 些 指 标 信息 会 以 “滚动 时 
间 窗 ”与 “ 桶 ”结合 的 方式 进行 汇总 ， 并 在 内 存 中 驻 留 一 段 时 间 ， 以 供 内 
部 或 外 部 这 间 行 查询 使 用 ，Hystrix 仪 表盘 就 是 这 些 指标 内 容 的 消 络 者 之 


通过 之 前 前 的 内 容 ， 我 们 已 经 体验 到 了 Spring Cloud 对 Hystrix 的 优雅 整 
合 。 除 此 之 外 ，Spring Cloud 还 完美 地 整合 了 尼 的 仪表 盘 组 什 Hystrix 
Dashboard， 它 主要 用 来 实时 监 0 信息 。 通 过 Hystrix 
Dashboard 有 反馈 的 实时 信息 ， ee 束 发 现 系 统 中 存在 的 问 

题 ， 从 而 及 时 地 采取 应 对 措施 。 

本 市 中 我 们 将 在 ”Hystrix 入门 例 子 的 基础 上 ， 构 建 一 个 Hystrix 
Dashboard ”来 对 RIBBON-CONSUMER 实 现 监 控 ， 完 成 后 的 架构 如 下 图 
所 示 。 


在 Spring Cloud 中 构建 一 个 Hystrix Dashboard 非 党 简单 ， 只 需要 下 面 4 
步 : 

e 创 建 一 个 标准 的 Spring Boot 工 程 ， 命 名 为 hystrix-dashboard。 

e 编 辑 pom.xml， 上 有 具体 依赖 内 容 如 下 所 示 : 

<parent> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-parent</artifactId> 

<version>Brixton.SR5</version> 

<relativePath /> <!--lookup parent from repository--> 

</parent> 

<dependencies> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-hystrix</artifactId> 

</dependency> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-hystrix-dashboard</artifactId> 














</dependency> 

<dependency> 

<groupId>org.Springframework.boot</groupId> 
<artifactId>spring-boot-starter-actuator</artifactId> 

</dependency> 

</dependencies> 

e 为 应 用 主 类 加 上 @EnableHystrixDashboard， 启 用 Hystrix Dashboard 








e 根 据 实际 情况 修改 application.properties 配置 文件 ， 比 如 选择 一 个 
未 被 占用 的 端口 等 ， 此 步 不 是 必需 的 。 

spring.application.name=hystrix-dashboard 

server.port=2001 

到 这 里 我 们 已 经 完成 了 基本 配置 ， 接 下 来 可 以 局 动 该 应 用 ， 并 访问 
http://localhost:2001/hystrix。 可 以 看 到 如 下 页 面 : 


这 是 Hystrix ”Dashboard 的 监控 首页 ， 该 页 面 中 并 没有 具体 的 监控 信 
轧 。 从 页 面 的 文字 扩容 中 我 们 可 以 知道 ，Hystrix Dashboard 共 文 持 三 种 
不 同 的 监控 方式 ， 如 下 所 示 。 





ee 默认 的 集群 监控 : 通过 URLhttp://turbine- 
hostname:port/turbine.stream 开 启 ， 实 现 对 默认 集群 的 监控 。 

e 指 定 的 集群 监控 : 通过 URLhttp://turbine- 
hostname:port/turbine.stream? cluster=[clusterName] 开 启 ， 实 现 对 


clusterName 集 群 的 监控 。 

e 单 体 应 用 的 监控 : ”通过 URLhttp://hystrix-app:port/hystrix.stream 开 
启 ， 实 现 对 具体 某 个 服务 实例 的 监控 。 

前 两 者 都 是 对 集群 的 监控 ， 需 要 整合 Turbine 才 能 实现 ， 这 部 分 内 容 
我 们 将 在 下 一 节 中 做 详细 介绍 。 在 本 节 中 ， 我 们 主要 实现 对 单个 服务 实 
例 的 监控 ， 这 里 我 们 先 来 实现 单个 服务 实例 的 监控 。 

既然 Hystrix Dashboard 监 控 单 实例 节点 需要 通过 访问 实例 
的 mystrix.stream 接 口 来 实现 ， 我 们 自然 需要 为 服务 实例 添加 这 个 端点 ， 
而 添加 该 功能 的 步骤 也 同样 简单 ， 只 需要 下 面 两 步 。 

e 在 服务 实例 pom.xml 中 的 dependencies 节 点 中 新 增 spring-boot- 
starteractuator 监控 模块 以 开局 监控 相关 的 端点 ， 并 确保 已 经 引入 断路 器 
的 依赖 spring-cloud-starter-hystrix: 

<dependencies> 











<dependency> 


<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-hystrix</artifactId> 

</dependency> 

<dependency> 

<groupId>org.Springframework.boot</groupId> 

<artifactId>spring-boot-starter-actuator</artifactId> 

</dependency> 

</dependencies> 

e 确 保 在 服务 实例 的 主 类 中 己 经 使 用 @EnableCircuitBreaker 注解 ， 开 
司 了 断路 器 功能 。 

在 为 RIBBON-CONSUMER 加 入 上 面 的 配置 之 后 ， 重 局 它 的 实例 ， 此 
时 我 们 可 以 在 控制 侣 中 看 到 打印 了 大 量 的 监控 端点 ， 其 中 /ystrix.stream 
就 是 用 于 Hystrix Dashboard 来 展现 监控 信息 的 接口 。 

0.s.b.a.e.mvc.EndpointHandlerMapping . Mapped 
{[/hystrix.stream/**]}" onto 

public org.springframework.web.servlet.ModelAndView 

org.springframework.cloud.netflix.endpoint.ServletWrappingEndpoint.har 

vlet.http.HttpServletRequest,javax.servlet.http.HttpServletResponse) 
throws 

java.lang.Exception 

到 这 里 已 经 完成 了 所 有 的 配置 ， 在 Hystrix Dashboard 的 首页 输入 
http://localhost:9000/hystrix.stream， 可 以 看 到 已 启动 对 RIBBON- 
CONSUMER 的 监控 ， 单 击 Monitor Stream 按 钮 ， 可 以 看 到 如 下 页 面 。 


先 看 看 在 首页 中 我 们 还 没有 介绍 的 另外 
两 个 参数 。 

eDelay: 该 参数 用 来 控制 服务 器 上 轮 询 监控 信息 的 延迟 时 间 ， 默 认 
为 2000 毫 秒 ， 可 以 通过 配置 该 属性 来 降低 客户 端的 网 络 和 CPU 消耗 。 

eTitle: 该 参数 对 应 了 上 网 头 部 标题 Hystrix Stream 之 后 的 内 容 ， 默 
认 会 使 用 具体 监控 实例 的 URL， 可 以 通过 配置 该 信息 来 展示 更 合适 的 标 
题 。 

回 到 监控 页 面 ， 我 们 来 详细 说 说 其 中 各 元 素 的 具体 含义 。 

e 可 以 在 监控 信息 的 左上 部 找到 两 个 重要 的 图 形 信 息 : 一 个 实心 贺 和 
一 条 曲线 。 

卓 实 心 圆 : 其 有 两 种 含义 。 通 过 颜色 的 变化 代表 了 实例 的 健康 程度 ， 
如 下 图 所 示 ， 它 的 健康 度 从 绿色 、 黄 色 、 橙 色 、 红 色 递 减 。 该 实心 圆 除 
了 颜色 的 变化 之 外 ， 它 的 大 小 也 会 根据 实例 的 请 求 流量 发 生变 化 ， 流 量 


下 








越 大 该 实心 圆 束 越 大 。 所 以 通过 该 实心 圆 的 展示 ， 我 们 可 以 在 大 量 的 实 
例 中 快速 及 现 故 障 实例 和 高 压力 实例 。 


田 曲 线 : 用 来 记录 2 分 钟 内 流量 的 相对 变化 ， 可 以 通过 它 来 观察 流量 
的 上 升 和 下 降 趋 势 。 
e 其 他 一 些 数量 指标 如 下 图 所 示 。 


通过 本 节 内 容 我 们 已 经 能 够 使 用 Hystrix Dashboard 来 对 单个 实例 做 信 
恩 监控 了 ， 但 是 在 分 布 式 系统 中 ， 往 往 有 非常 多 的 实例 需要 去 维护 和 监 
控 。 到 目前 为 止 ， 我 们 能 做 的 束 是 通过 开启 多 个 窗口 来 监控 多 个 实例 ， 
很 显然 这 样 的 做 法 并 不 合理 。 在 下 一 节 中 ， 我 们 将 介绍 利用 Turbine 和 
Hystrix Dashboard 配 合 实现 对 集群 的 监控 。 

注意 : 当 使 用 Hystrix Board 来 监控 Spring Cloud Zuul 构 建 的 API 网 关 
时 ，Thread Pool 信 息 会 一 直 处 于 Loading 状 态 。 这 是 由 于 Zuul 默 认 会 使 用 
信号 量 来 实现 隔离 ， 只 有 通过 Hystrix 配 置 把 隔离 机 制 改 为 线程 池 的 方式 
才能 够 得 以 展示 。 

















Turbine 集 和 群 监控 


在 上 一 节 介绍 Hystrixz Dashboard 的 首页 时 ， 我 们 提 到 过 除了 可 以 开启 
单个 实例 的 监控 页 面 之 外 ， 还 有 一 个 监控 端点 /Hturbine.stream 是 对 集群 使 
用 的 。 从 端点 的 命名 中 ， 可 猜测 到 这 里 我 们 将 引入 Turbine， 通 过 它 来 汇 
集 监控 信息 ， 并 将 聚合 后 的 信息 提供 给 Hystrix Dashboard 来 集中 展示 和 
监控 。 


构建 监控 聚合 服务 


下 面 我 们 将 在 上 一 节 内 容 的 基础 上 做 一 些 扩展 ， 通 过 引入 Turbine 来 
聚合 RIBBON-CONSUMER 服 务 的 监控 信息 ， 并 输出 给 Hystrix 
Dashboard 来 进行 展示 ， 最 后 完成 如 下 图 所 示 的 结构 。 


具体 实现 步骤 如 下 : 

e 创 建 一 个 标准 的 Spring Boot 工 程 ， 命 名 为 turbine。 

e 编 辑 pom.xml， 有 具体 依赖 内 容 如 下 所 示 。 

<properties> 

<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> 

<project.reporting.outputEncoding>UTF- 
8</project.reporting.outputEncoding> 

<java.version>1.8</java.version> 

</properties> 

<parent> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-parent</artifactId> 

<version>Brixton.SR5</version> 

<relativePath /> <!--lookup parent from repository--> 

</parent> 

<dependencies> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-turbine</artifactId> 

</dependency> 

<dependency> 

<groupId>org.Springframework.boot</groupId> 








<artifactId>spring-boot-starter-actuator</artifactId> 

</dependency> 

</dependencies> 

e 创 建 应 用 主 类 TurbineApplication， 并 使 用 @EnableTurbine 注解 开 
启 Turbine。 

(@@EnableTurbine 

@EnableDiscoveryCljlient 

SpringBootApplication 

public class TurbineApplication { 

public static void main (String[largs) { 

SpringApplication.run (TurbineApplication.class,args) ; 


} 
在 application.properties 中 加 入 Eureka 和 Turbine 的 相关 配置 ， 有 具体 如 


Spring.application.name=turbine 

server.port=8989 

management.port=8990 

eureka.client.serviceUTrl.defaultZone=http://localhost:1111/eureka/ 

turbine.app-config=RIBBON-CONSUMER 

turbine.cluster-name-expression="default" 

turbine.combine-host-port=true 

其 中 ，turbine.app-config ”参数 指定 了 需要 收集 监控 信息 的 服务 名 ; 
turbine.cluster-name-expression 参数 指定 了 集群 名 称 为 default， 当 服务 数 
量 非 常 多 的 时 候 ， 可 以 启动 多 个 Turbine 服务 来 构建 不 同 的 聚合 集群 ， 
而 该 参数 可 以 用 来 区 分 这 些 不 同 的 聚合 集群 ， 同 时 该 参数 值 可 以 在 
Hystrix 仪 表盘 中 用 来 定位 不 同 的 聚合 集群 ， 只 需 在 Hystrix Stream 的 
URL 中 通过 duster 参数 来 指定 ; turbine.combine-host-port 参 数 设 置 为 
true， 可 以 让 同一 主机 上 的 服务 通过 主机 名 与 端口 写 的 组 合 来 进行 区 
分 ， 默 认 情 况 下 会 以 host 来 区 分 不 同 的 服务 ， 这 会 使 得 在 本 地 调试 的 时 
候 ， 本 机 上 的 不 同 服务 聚合 成 一 个 服务 来 统计 。 

在 完成 了 上 面 的 内 容 构 建 之 后 ， 我 们 来 体验 一 下 Turbine 对 集群 的 监 
控 能 力 。 分 别 启动 eureka-server、HELLO-SERVICE、RIBBON- 
CONSUMER、Turbine ”以 及 Hystrix Dashboard。 访 问 Hystrix 
Dashboard， 并 开启 对 http://localhost:8989/turbine.stream 的 监控 ， 我 们 可 
以 看 到 如 下 页 面 : 


从 图 中 可 以 看 到 ， 虽 然 我 们 如 之 前 的 架构 那样 启动 了 两 个 RIBBON- 
CONSUMER， 但 是 在 监控 页 面 中 依然 只 是 展示 了 一 个 监控 图 。 不 过 仔 
细 的 读者 可 能 已 经 发 现 ， 图 中 集群 报告 区 域 中 的 Hosts 属性 与 之 前 尝试 
单机 监控 时 已 经 有 所 不 同 。 由 此 我 们 可 以 知道 RIBBON-CONSUMER 启 
动 了 两 个 实例 ， 这 里 只 展现 了 一 个 监控 图 ， 是 由 于 这 两 个 实例 是 同一 个 
服务 ， 而 对 于 集群 来 说 我 们 关注 的 是 服务 集群 的 高 可 用 性 ， 所 以 Turbine 
会 将 相同 服务 作为 整体 来 看 待 ， 并 汇总 成 一 个 监控 图 。 

也 可 以 为 RIBBON-CONSUMER 设置 一 个 新 的 
spring.application.name， 比 如 ribbon-consumer-2， 并 启动 它 ， 此 时 我 们 
就 有 两 个 服务 会 将 监控 信息 输出 给 Turbine 汇总 了 。 刷 新 之 前 的 监控 页 
面 ， 可 以 看 到 如 下 有 两 个 监控 图 的 页 面 : 














= 消 局 代 理 结 合 


Spring Cloud 在 封装 Turbine 的 时 候 ， 还 封装 了 基于 消息 代理 的 收集 实 
现 。 所 以 ， 我 们 可 以 将 所 有 需要 收集 的 监控 信息 都 输出 到 消息 代理 中 ， 
然后 Turbine 服 务 再 从 消息 代理 中 异步 获取 这 些 监控 信息 ， 最 后 将 这 些 监 
控 信 息 聚 合并 输出 到 Hystrix Dashboard 中 。 通 过 引入 消息 代理 ， 我 们 的 
Turbine 和 Hystrix ”Dashboard 实 现 的 监控 架构 可 以 改 成 如 下 图 所 示 的 结 
构 。 


从 图 中 可 以 看 到 ， 这 里 多 了 一 个 重要 元 素 RabbitMQ。 对 于 RabbitMQ 
的 安装 我 们 可 以 查看 第 9 章 的 相关 内 容 ， 这 里 不 做 过 多 说 明 。 下 面 ， 我 
们 来 构建 一 个 新 的 应 用 以 实现 基于 消 恩 代理 的 Turbine 聚 合 服务 ， 具 体 步 
又 如 下 所 示 。 

e 创 建 一 个 标准 的 Spring Boot 工 程 ， 命 名 为 turbine-amqp。 

e 编 辑 pom.xml， 上 有 具体 依赖 内 容 如 下 所 示 : 

<properties> 

<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> 

<project.reporting.outputEncoding>UTF- 
8</project.reporting.outputEncoding> 

<java.version>1.8</java.version> 

</properties> 

<parent> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-parent</artifactId> 











<version>Brixton.SR5</version> 

<relativePath /> <!--lookup parent from repository--> 

</parent> 

<dependencies> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-turbine-amqp</artifactId> 

</dependency> 

<dependency> 

<groupId>org.Springframework.boot</groupId> 

<artifactId>spring-boot-starter-actuator</artifactId> 

</dependency> 

</dependencies> 

可 以 看 到 这 里 主要 引入 了 spring-cloud-starter-turbine-amqp 依 赖 ， 它 实 
际 上 包装 了 Spring-cloud-starter-turbine-stream 和 和 pring-cloud- 
starterstream-rabbit。 

注意 : 这 里 我 们 需要 使 用 Java 8 来 运行 。 

e 在 应 用 主 类 中 使 用 @EnableTurbineStream 注 解 来 启用 Turbine Stream 
的 配置 。 

(@OEnableTurbineStream 

@EnableDiscoveryCljlient 

SpringBootApplication 

public class Turbine Application { 

public static void main (String[]args) { 

SpringApplication.run (TurbineApplication.class,args) ; 


} 





} 

e 配 置 application.properties 文 件 。 

Spring.application.name=turbine 

server.port=8989 

management.port=8990 

eureka.client.serviceUTrl.defaultZone=http://localhost:1111/eureka/ 

对 于 Turbine 的 配置 已 经 完成 了 ， 下 面 需要 对 服务 消费 者 RIBBON- 
CONSUMER 做 一 些 修改 ， 使 其 监控 信息 能 够 输出 到 Rabbit+MQ 上 。 这 个 
修改 也 非常 简单 ， 只 需 在 pom.xml 中 增加 对 spring-cloud-netflix-hystrix- 
amqp 的 依赖 ， 有 具体 如 下 : 


<dependencies> 








<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-netflix-hystrix-amqp</artifactId> 

</dependency> 

</dependencies> 

在 完成 了 上 面 的 配置 之 后 ， 继 续 局 动 eureka-server、HELLO- 
SERVICE、RIBBON-CONSUMER、Turbine 以 及 Hystrix Dashboard， 同 
时 确保 RabbitMQ 已 在 正常 运行 。 访 问 Hystrix Dashboard， 并 开局 对 
http://localhost:8989/turbine.stream 的 监控 ， 我 们 可 以 获得 如 之 前 实现 的 
同样 结果 ， 只 是 这 里 的 监控 信息 收集 是 通过 消 恩 代理 异步 实现 的 。 
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通过 前 两 章 对 Spring Cloud Ribbon 和 Spring Cloud Hystrix 的 介绍 ， 我 
们 已 经 掌握 了 开发 微服 务 应 用 时 的 两 个 重 磅 武器 ， 学 会 了 如 何在 微服 务 
架构 中 实现 客户 端 负载 均衡 的 服务 调用 以 及 如 何 通过 上 断路 喜来 保护 我 们 
的 微服 务 应 用 。 这 两 者 将 被 作为 基础 工具 类 框架 广泛 地 应 用 在 各 个 微服 
务 的 实现 中 ， 不 仅 包括 我 们 上 自身 的 业务 类 微服 务 ， 也 包括 一 些 基 础 设施 
类 微服 务 〈 比 如 网 关 ) 。 此 外 ， 在 实践 过 程 中 ， 我 们 会 发 现 对 这 两 个 框 
架 的 使 用 几乎 是 同时 出 现 的 。 既 然 如 此 ， 那 么 是 否 有 更 高 层次 的 封装 来 
整合 这 两 个 基础 工具 以 简化 开发 呢 ?” 本 章 我 们 即将 介绍 的 Spring Cloud 
Feign 就 是 这 样 一 个 工具 。 它 基于 Netflix Feign 实 现 ， 整 合 了 Spring Cloud 
Ribbon 与 Spring Cloud Hystrix， 除 了 提供 这 两 者 的 强大 功能 之 外 ， 它 还 
提供 了 一 种 声明 式 的 Web 服 务 客户 端 定义 方式 。 

我 们 在 使 用 Spring Cloud Ribbon 时 ， 通 常 都 会 利用 它 对 RestTemplate 
的 请 求 拦 截 来 实现 对 依赖 服务 的 接口 调用 ， 而 RestTemplate 已 经 实现 了 
对 HTTP 请 求 的 封装 处 理 ， 形 成 了 一 套 模 板 化 的 调用 方法 。 在 之 前 的 例 
子 中 ， 我 们 只 是 简单 介绍 了 RestTemplate 调 用 的 实现 ， 但 是 在 实际 开发 
中 ， 由 于 对 服务 依赖 的 调用 可 能 不 止 于 一 处 ， 往 往 一 个 接口 会 被 多 处 调 
用 ， 上 所 以 我 们 通 第 都 会 针对 各 个 微服 务 自行 封装 一 些 客户 端 类 来 包装 这 
些 依赖 服务 的 调用 。 这 个 时 候 我 们 会 发 现 ， 由 于 RestTemplate 的 封装 ， 
几乎 每 一 个 调用 都 是 简单 的 模板 化 内 容 。 综 合 上 述 这 些 情况 ，Spring 
Cloud Feign 在 此 基础 上 做 了 进一步 封装 ， 由 它 来 帮助 我 们 定义 和 实现 依 
赖 服务 接口 的 定义 。 在 Spring Cloud Feign 的 实现 下 ， 我 们 只 需 创建 一 个 
接口 并 用 注解 的 方式 来 配置 它 ， 即 可 完成 对 服务 提供 方 的 接口 绑 定 ， 简 
化 了 在 使 用 Spring Cloud Ribbon 时 自行 封装 服务 调用 客户 端的 开发 量 。 
Spring Cloud Feign 上 具备 可 插 拔 的 注解 文 持 ， 包 括 Feign 注 解 和 JAX-RS 注 
解 。 同 时 ， 为 了 适应 Spring 的 广大 用 户 ， 它 在 Netflix Feign 的 基础 上 扩展 
了 对 Spring MVC 的 注解 支持 。 这 对 于 习惯 于 Spring MVC 的 开发 者 来 
说 ， 无 疑 是 一 个 好 消息 ， 因 为 这 样 可 以 大 大 减少 学 习 使 用 它 的 成 本 。 男 
外 ， 对 于 Feign 自身 的 一 些 主 要 组 件 ， 比 如 编码 器 和 人 解码 器 等 ， 它 也 以 
可 插 拔 的 方式 提供 ， 在 有 需求 的 时 候 我 们 可 以 方便 地 扩展 和 蔡 换 它们 。 
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在 本 节 中 ， 我 们 将 通过 一 个 简单 的 示例 来 展现 Spring Cloud Feign 在 
服务 客户 器 定义 上 上 所 再 来 的 便利 。 下 面 的 示例 将 继续 使 用 之 前 我 们 实现 
的 hello-service 服 务 ， 这 里 我 们 会 通过 Spring Cloud Feign 提 供 的 声明 式 服 
务 绑 定 功能 来 实现 对 该 服务 接口 的 调用 。 

e 首 先 ， 创 建 一 个 Spring ”Boot 基础 工程 ， 取 名 为 feign-consumer， 并 
在 pom.xml 中 引入 spring-cloud-starter-eureka 和 spring-cloud-starter-feign 依 
赖 。 具 体内 容 如 下 所 示 : 

<parent> 

<groupId>org.Springframework.boot</groupId> 

<artifactId>spring-boot-starter-parent</artifactId> 

<version>1.3.7.RELEASE</version> 

<relativePath/> <!--lookup parent from repository--> 

</parent> 

<dependencies> 

<dependency> 

<groupId>org.Springframework.boot</groupId> 

<artifactId>spring-boot-starter-web</artifactId> 

</dependency> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-eureka</artifactId> 

</dependency> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-feign</artifactId> 

</dependency> 

</dependencies> 

<dependencyManagement> 

<dependencies> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-dependencies</artifactId> 

<version>Brixton.SR5</version> 

<type>pom</type> 


<SCOpe>import</Scope> 

</dependency> 

</dependencies> 

</dependencyManagement> 

e 创 建 应 用 主 类 ConsumerApplication， 并 通过 @EnableFeignClients 注 
解 开 局 Spring Cloud Feign 的 支持 功能 。 

EnableFeignCjlients 

@EnableDiscoveryCljlient 

SpringBootApplication 

public class ConsumerApplication { 

public static void main (String[largs) { 

SpringApplication.run (ConsumerApplication.class,args) ; 

} 

} 

e 定 义 HelloService 接 口 ， 通 过 @FeignClient 注 解 指定 服务 名 来 绑 定 服 
务 ， 然 后 再 使 用 Spring ”MVC 的 注解 来 绑 定 具体 该 服务 提供 的 REST 接 
口 。 





@FeignClient ("hello-service") 

public interface HelloService { 

@RequestMapping ("/hello") 

String hello (); 

} 

注意 : 这 里 服务 名 不 区 分 大 小 写 ， 所 以 使 用 hello-service 和 HELLO- 
SERVICE 都 是 可 以 的 。 另 外 ， 在 Brixton.SR5 版 本 中 ， 原 有 的 serviceld 
属性 已 经 被 废弃 ， 若 要 写 属性 名 ， 可 以 使 用 name 或 value。 

e 接 着 ， 创 建 一 个 _ ConsumerController 来 实现 对 Feign 客户 端的 调 
用 。 使 用 @Autowired 直 接 注 入 上 和 面 定 义 的 HelloService 实 例 ， 并 在 
helloConsumer 函 数 中 调用 这 个 绑 定 了 hello-service 服务 接口 的 客户 并 来 
问 该 服务 发 起 hello 接口 的 调用 。 

(DRestController 

public class ConsumerController { 

(OAutowired 

HelloService helloService; 

@ReduestMapping (value="/feign- 
consumer",method=RequestMethod.GET) 

public String helloConsumer () { 

return helloService.hello (); 


e 最 后 ， 同 Ribbon 实 现 的 服务 消费 者 一 样 ， 需 要 在 
application.properties 中 指定 服务 注册 中 心 ， 并 定义 自身 的 服务 名 为 feign- 
consumer， 为 了 方便 本 地 调试 与 之 前 的 Ribbon 消 费 者 区 分 ， 端 口 使 用 
9001 。 

Spring.application.name=feign-consumer 

server.port=9001 

eureka.client.serviceUTrl.defaultZone=http://localhost:1111/eureka/ 

测试 验证 

如 之 前 验证 Ribbon 客户 端 负 载 均衡 一 样 ， 我 们 先 启动 服务 注册 中 心 
以 及 两 个 HELLO-SERVICE， 然 后 局 动 FEIGN-CONSUMER， 此 时 我 们 
在 Eureka 信息 面板 中 可 看 到 如 下 内 容 : 


发 送 几 次 GET 请 求 到 http://localhost:9001/feign-consumer， 可 以 得 到 
如 之 前 Ribbon 实 现时 一 样 的 效果 ， 正 确 返 回 了 “Hello World”。 并 且 根 据 
控制 台 的 输出 ， 我 们 可 以 看 到 Feign 实 现 的 消费 者 ， 依 然 是 利用 Ribbon 
维护 了 针对 HELLO-SERVICE 的 服务 列表 信息 ， 并 且 通 过 轮 询 实 现 了 客 
户 端 负 载 均 衡 。 而 与 Ribbon 不 同 的 是 ， 通 过 Feign 我 们 只 需 定 义 服务 绑 
定 接口 ， 以 声明 式 的 方法 ， 优 雅 而 简单 地 实现 了 服务 调用 。 
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在 上 一 节 的 示例 中 ， 我 们 使 用 Spring Cloud Feign 实 现 的 是 一 个 不 带 
参数 的 REST 服 务 绑 定 。 然 而 现实 系统 中 的 各 种 业务 接口 要 比 它 复杂 得 
多 ， 我 们 会 在 HITP 的 各 个 位 置 传 入 各 种 不 同类 型 的 参数 ， 并 且 在 返回 
请 求 响 应 的 时 候 也 可 能 是 一 个 复杂 的 对 象 结构 。 在 本 节 中 ， 我 们 将 详细 
介绍 Feign 中 对 几 种 不 同形 式 参 数 的 绑 定 方法 。 

在 开始 介绍 Spring Cloud Feign 的 参数 绑 定 之 前 ， 我 们 先 扩 展 一 下 上 服 
务 提 供 方 hello-service。 增 加 下 面 这 些 接口 定义 ， 其 中 包含 带 有 Request 
参数 的 请 求 、 融 有 Header 信 息 的 请 求 、 带 有 RequestBody 的 请 求 以 及 请 
求 响应 体 中 是 一 个 对 象 的 请 求 。 

@RequestMapping (value="/hellol",method=RequestMethod.GET) 

public String hello (@RequestParam String name) { 

return "Hello "+name; 

J 

@RequestMapping (value="/hello2",method=RequestMethod.GET) 

public User hello (@RequestHeader String Dame,@RequestHeader 
Integer age) { 

return new User (name,age) ; 

@RequestMapping (value="/hello3",method=RequestMethod.POST) 

public String hello (@RequestBody User user) { 

return "Hello "+user.getName () +","+user.getAge (); 

} 

User 对 象 的 定义 如 下 ， 这 里 省 略 了 getter 和 setter 函 数 ， 需 要 注意 的 
是 ， 这 里 必须 要 有 User 的 默认 构造 函数 。 不 然 ，Spring Cloud Feign 根 据 
JSON 字 符 串 转 换 User 对 象 时 会 抛 出 异常 。 

public class User { 

private String name; 

private Integer age; 

public User () { 

} 

public User (String name,Integer age) { 

this.name=name; 

this.age=age; 


} 





/省 略 getter 和 setter 

(DOverride 

public String toString () { 

return "name="+name+",age="+age,; 

} 

} 

在 完成 了 对 hello-service 的 改造 之 后 ， 下 面 我 们 开始 在 快速 入 门 示 例 
的 feign-consumer 应 用 中 实现 这 些 新 增 的 请 求 的 绑 定 。 

e 首 先 ， 在 feign-consumer 中 创建 与 上 面 一 样 的 User 类 。 

e 然 后 ， 在 ”HelloService 接口 中 增加 对 上 述 三 个 新 增 接口 的 绑 定 声 
明 ， 修 改 后 ， 完 成 的 HelloService 接 口 如 下 所 示 : 

@FeignClient ("HELLO-SERVICE") 

public interface HelloService { 

@RequestMapping ("/hello") 

String hello (); 

@RequestMapping (value="/hellol",method=RequestMethod.GET) 

String hello (@RequestParam ("name") String name) ; 

@RequestMapping (value="/hello2",method=RequestMethod.GET) 

User hello (@RequestHeader ("name") String 
name,@RequestHeader ("age") Integer age) ; 

@RequestMapping (value="/hello3",method=RequestMethod.POST) 

String hello (@RequestBody User user) ; 

} 

这 里 一 定 要 注意 ， 在 定义 各 参数 绑 定 时 ，@RequestParam、 
@RequestHeader 等 可 以 指定 参数 名 称 的 注解 ， 它 们 的 value 干 万 不 能 少 。 
在 Spring MVC 程序 中 ， 这 些 注解 会 根据 参数 名 来 作为 默认 值 ， 但 是 在 
Feign 中 绑 定 参数 必须 通过 value 属 性 来 指明 具体 的 参数 名 ， 不 然 会 抛 出 
IlegalStateException 异 常 ，value 属 性 不 能 为 空 。 

Caused by: java.lang.IllegalStateException: RequestParam.value () was 
empty on parameter 0 

at feign.Util.checkState (Util.java:128) 

e 最 后 ， 在 ConsumerController 中 新 增 一 个 /feign-consumer2 接 口 ， 来 
对 本 市 新 增 的 声明 接口 进行 调用 ， 修 改 后 的 完整 代码 如 下 所 示 : 

(DRestController 

public class ConsumerController { 

(OAutowired 

HelloService helloService; 








@ReduestMapping 〈value='"/feign- 
consumer",method=RequestMethod.GET) 

public String helloConsumer () { 

return helloService.hello (); 

} 

@RequestMapping (value="/feign- 
consumer2",method=RequestMethod.GET) 

public String helloConsumer2 () { 

StringBuilder sb=new StringBuilder () ; 

sb.append (helloService.hello () ) .append 〈"\n" ) ; 

sb.append (helloService.hello ("DIDI") ) .append 〈"\n" ) ; 

sb.append (helloService.hello ("DIDI",30) ) .append ("\n"); 

sb.append (helloService.hello (new 
User ("DIDI",30) ) ) .append ("\n" ) ; 

return sb.toString () ; 

} 

} 

测试 验证 

在 完成 上 述 改 造 之 后 ， 启 动 服务 注册 中 心 、 两 个 hello-service 服 务 以 
及 我 们 改造 过 的 feign-consumer。 通 过 发 送 GET 请 求 到 
http://localhost:9001/feign-consumer2， 触 发 HelloService 对 新 增 接口 的 调 
用 。 最 终 ， 我 们 会 获得 如 下 和 输出， 代表 接 口 绑 定 和 调用 成 功 。 

Hello World 

Hello DIDI 

name=DIDI,age=30 

Hello DIDI,30 


继承 特性 


通过 “快速 入 门 ? 以 及 “参数 绑 定 ? 小 节 中 的 示例 实践 ， 相 信 很 多 读者 
已 经 观察 到 ， 当 使 用 Spring MVC 的 注解 来 绑 定 服务 接口 时 ， 我 们 几乎 
完全 可 以 从 服务 提供 方 的 Controller 中 依靠 复制 操作 ， 构 建 出 相应 的 服务 
客户 端 绑 定 接口 。 既 然 存 在 这 么 多 复制 操作 ， 我 们 目 然 需 要 考虑 这 部 分 
内 容 是 个 可 以 得 到 进一步 的 抽象 呢 ? 在 Spring Cloud Feign 中 ， 针 对 该 问 
题 提供 了 继承 特性 来 帮助 我 们 解决 这 些 复 制 操作 ， 以 进一步 减少 编码 
量 。 下 面 ， 我 们 详细 看 看 如 何 通 过 Spring Cloud Feign 的 继承 特性 来 实现 
REST 接 口 定义 的 复 用 。 

e 为 了 能 够 复 用 DTO 与 接口 定义 ， 我 们 先 创建 一 个 基础 的 Maven 工 
程 ， 命 名 为 hello-service-api。 

e 由 于 在 hello-service-api 中 需要 定义 可 同时 复 用 于 服务 端 与 客户 端 
的 接口 ， 我 们 要 使 用 到 Spring MVC 的 注解 ， 所 以 在 pom.xml 中 引入 
spring-bootstarter-web 依 赖 ， 具 体内 容 如 下 所 示 : 

<groupId>com.didispace</groupId> 

<artifactId>hello-service-api</artifactId> 

<version>0.0.1-SNAPSHOT</version> 

<packaging>jar</packaging> 

<name>hello-service-api</name> 

<parent> 

<groupId>org.Springframework.boot</groupId> 

<artifactId>spring-boot-starter-parent</artifactId> 

<version>1.3.7.RELEASE</version> 

<relativePath/> <!--lookup parent from repository--> 

</parent> 

<properties> 

<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> 

<project.reporting.outputEncoding>UTF- 
8</project.reporting.outputEncoding> 

<java.version>1.8</java.version> 

</properties> 

<dependencies> 

<dependency> 

<groupId>org.Springframework.boot</groupId> 

<artifactId>spring-boot-starter-web</artifactId> 





</dependency> 

</dependencies> 

e 将 上 一 节 中 实现 的 User 对 象 复制 到 hello-service-api 工程 中 ， 比 如 
保存 到 com.didispace.dto.User。 

e 在 hello-service-api 工 程 中 创建 com.didispace.service.HelloService 接 
口 ， 内 容 如 下 ， 该 接口 中 的 User 对 象 为 本 项 目 中 的 
com.didispace.dto.User。 

e 将 上 一 市 中 实现 的 User 对 象 复制 到 com.didispace.dto.User。 创 建 
com.didispace.service.HelloService 接口 ， 内 容 如 下 ， 该 接口 中 的 User 对 
象 为 本 项 目 中 的 com.didispace.dto.User。 

@RequestMapping ("/refactor") 

public interface HelloService { 

@RequestMapping (value="/hello4",method=RequestMethod.GET) 

String hello (@RequestParam ("name") String name) ; 

@RequestMapping (value="/hello5",method=RequestMethod.GET) 

User hello (@RequestHeader ("name") String 
name,@RequestHeader ("age") Integer age) ; 

@RequestMapping (value="/hello6",method=RequestMethod.POST) 

String hello (@RequestBody User user) ; 

} 

因为 后 续 还 会 通过 之 前 的 hello-service 和 feign-consumer 来 重 构 ， 所 以 
为 了 避免 接口 混 消 ， 在 这 里 定义 HelloService 时 ， 除 了 头 部 定义 
了 /rafactor 前 级 之 外 ， 同 时 将 提供 服务 的 三 个 接口 更 名 
为 /hello4、/hello5、/hello6。 

e 下 面 对 hello-service 进行 重 构 ， 在 pom.xml 的 dependency 节点 中 ， 
新 增 对 hello-service-api 的 依赖 。 

<dependency> 

<groupId>com.didispace</groupId> 

<artifactId>hello-service-api</artifactId> 

<version>0.0.1-SNAPSHOT</version> 

</dependency> 

e 创 建 RefactorHelloController 类 继承 hello-service-api 中 定义 的 
HelloService 接 口 ， 并 参考 之 前 的 HelloController 来 实现 这 三 个 接口 ， 具 
体内 容 如 下 所 示 : 

(DRestController 

public class RefactorHelloController implements HelloService { 

(DOverride 








public String hello (@RequestParam ("name") String name) { 

return "Hello "+name; 

} 

(DOverride 

public User hello (@RequestHeader ("name") String 
name,@ORequestHeader ("age") Integer age) { 

return new User (name,age) ; 

} 

(DOverride 

public String hello (@RequestBody User user) { 

return "Hello "+user.getName () +","+user.getAge (); 


} 


} 

我 们 可 以 看 到 通过 继承 的 方式 ， 在 Controller 中 不 再 包含 以 往 会 定义 
的 请 求 映 射 注 解 @RequestMapping， 而 参数 的 注解 定义 在 重 写 的 时 候 会 
自动 带 过 来 。 在 这 个 类 中 ， 除 了 要 实现 接口 逻辑 之 外 ， 只 需 再 增加 
@RestController 注 解 使 该 类 成 为 一 个 REST 接 口 类 就 大 功 告 成 了 。 

e 完 成 了 服务 提供 者 的 重 构 ， 接 下 来 在 服务 消费 者 feign-consumer 的 
人 中 ， 如 在 服务 提供 者 中 一 样 ， 新 增 对 hello-service-api 的 依 

硕 。 

e 创 建 RefactorHelloService 接口 ， 并 继承 hello-service-api 包 中 的 
HelloService 接 口 ， 然 后 添加 @FeignClient 注 解 来 绑 定 服务 。 

@FeignClient (value="HELLO-SERVICE") 

public interface RefactorHelloService extends 
com.didispace.service.HelloService { 








} 

e 最 后 ， 在 ConsumerController 中 ， 注 入 RefactorHelloService 的 实例 ， 
并 新 增 一 个 请 求 /feign-consumer3 来 触发 对 RefactorHelloService 的 实例 的 
调用 。 

Autowired 

RefactorHelloService refactorHelloService; 

@ReduestMapping 〈value='"/feign- 
coOnsumer3",method=RedquestMethod.GET ) 

public String helloConsumer3 () { 

StringBuilder sb=new StringBuilder () ; 

sb.append (refactorHelloService.hello ("MIMI") ) .append ("\n"); 

sb.append (refactorHelloService.hello ("MIMI",20) ) .append ("\n") 


sb.append (refactorHelloService.hello (new 
com.didispace.dto.User ("MIMI",20) ) ) .append 〈"\n" ) ; 
return sb.toString (); 


} 

测试 验证 

这 次 的 验证 过 程 需要 注意 几 个 工程 的 构建 顺序 ， 由 于 hello-service 和 
feign-consumer 都 依赖 hello-service-api 工 程 中 的 接口 和 DTO 和 定义 ， 所 以 必 
须 先 构建 hello-service-api 工 程 ， 然 后 再 构建 hello-service 和 feign- 
consumer。 接 着 我 们 分 别 启 动 服务 注册 中 心 ，hello-service 和 feign- 
consumer， 并 访问 http://localhost:9001/feign-consumer3， 调 用 成 功 后 可 
以 获得 如 下 输出 : 

Hello MIMI 

name=MIMI,age=20 

Hello MIMI,20 

优点 与 缺点 

使 用 Spring Cloud Feign 继 承 特性 的 优点 很 明显 ， 可 以 将 接口 的 定义 
从 Controller 中 剥离 ， 同 时 配合 Maven 私 有 仓库 就 可 以 轻易 地 实现 接口 定 
义 的 共享 ， 实 现在 构建 期 的 接口 绑 定 ， 从 而 有 效 减 少 服 务 客户 端的 绑 定 
配置 。 这 么 做 虽然 可 以 很 方便 地 实现 接口 定义 和 依赖 的 共享 ， 不 用 再 复 
制 粘贴 接口 进行 绑 定 ， 但 是 这 样 的 做 法 使 用 不 当 的 话 会 带 来 副作用 。 由 
于 接口 在 构建 期 间 就 建立 起 了 依赖 ， 那 么 接口 变动 束 会 对 项 目 构 建造 成 
影响 ， 可 能 服务 提供 方 修改 了 一 个 接口 定义 ， 那 么 会 直接 导致 客户 端 工 
程 的 构建 失败 。 所 以 ， 如 果 开 发 团队 通过 此 方法 来 实现 接口 共享 的 话 ， 
建议 在 开发 评审 期 间 严 格 遵 守 面 同 对 象 的 开 闭 原则 ， 尽 可 能 地 做 好 前 后 
版 本 的 兼容 ， 防 止 府 一 发 而 动 全 里 的 后 果 ， 增 加 团队 不 必要 的 维护 工作 


里 。 


























Ribbon 瑟 置 


由 于 Spring Cloud Feign 的 客户 端 负 载 均 衡 是 通过 Spring Cloud Ribbon 
实现 的 ， 所 以 我 们 可 以 直接 通过 配置 Ribbon 客 户 端的 方式 来 自 定 义 各 个 
服务 客户 端 调 用 的 参数 。 那 么 我 们 如 何在 使 用 Spring Cloud Feign 的 工程 
中 使 用 Ribbon 的 配置 呢 ? 





全 局 配置 的 方法 非常 简单 ， 我 们 可 以 直接 使 用 ribbon.<key>=<value> 
的 方式 来 设置 ribbon 的 各 项 默认 人 参数。 比如， 修改 默认 的 客户 端 调 用 超 
时 时 间 : 

ribbon.ConnectTimeout=500 

ribbon.ReadTimeout=5000 


大 多 数 情 况 下 ， 我 们 对 于 服务 调用 的 超时 时 间 可 能 会 根据 实际 服务 
的 特性 做 一 些 调整 ， 所 以 仅仅 依靠 默认 的 全 局 配置 是 不 行 的 。 在 使 用 
Spring Cloud Feign 的 时 候 ， 人 针对 各 个 服务 客户 端 进行 个 性 化 配置 的 方式 
与 使 用 Spring Cloud Ribbon 时 的 配置 方式 是 一 样 的 ， 都 采用 
<client>.ribbon.key=value ”的 格式 进行 设置 。 但 是 ， 这 里 就 有 一 个 疑问 
了 ，<client> 所 指 代 的 Ribbon 客 户 端 在 哪里 呢 ? 

回想 一 下 ， 在 定义 Feign 客 户 端的 时 候 ， 我 们 使 用 了 @FeignClient 注 
解 。 在 初始 化 过 程 中 ，Spring Cloud Feign 会 根据 该 注解 的 name 属 性 或 
value 属 性 指定 的 服务 名 ， 自 动 创建 一 个 同名 的 Ribbon 客 户 端 。 也 整 是 
说 ， 在 之 前 的 示例 中 ， 使 用 @FeignClient (value="HELLO-SERVICE") 
来 创建 Feign 客户 端的 时 候 ， 同 时 也 创建 了 一 个 名 为 HELLO-SERVICE 
的 Ribbon 客 户 端 。 既 然 如 此 ， 我 们 就 可 以 使 用 @FeignClient 注 解 中 的 
name 或 value 属 性 值 来 设置 对 应 的 Ribbon 参 数 ， 比 如 : 

HELLO-SERVICE .ribbon.ConnectTimeout=500 

HELLO-SERVICE.ribbon.ReadTimeout=2000 

HELLO-SERVICE.ribbon.OkToRetryOnAllOperations=true 

HELLO-SERVICE.ribbon.MaxAutoRetriesNextServer=2 

HELLO-SERVICE.ribbon.MaxAutoRetries=1 








试 | 


在 Spring Cloud Feign 中 默认 实现 了 请 求 的 重 试 机 制 ， 而 上 面 我 们 对 
于 HELLO-SERVICE 客 户 端的 配置 内 容 就 是 对 于 请 求 超时 以 及 重 试 机 制 
配置 的 详情 ， 有 具体 内 容 可 参考 第 4 章 最 后 一 节 关 于 Spring Cloud Ribbon 重 
试 机 制 的 介绍 。 我 们 可 以 通过 修改 之 前 的 示例 做 一 些 验证 。 

e@ 在 hello-service 应 用 的 mhello 接 口 实现 中 ， 增 加 一 些 随机 延迟 ， 比 
如 : 

@RequestMapping (value="/hello",method=RequestMethod.GET) 

public String hello 〈) throws Exception { 

ServiceInstance instance=client.getLocalServiceInstance () ; 

// 测 试 超时 

int sleepTime=new Random () .nextInt (3000); 

logger.info ("sleepTime:"+sleepTime) ; 

Thread.sleep (sleepTime) ; 

logger.info ("/hello,host:"+instance.getHost () +",service id:"+ 

instance.getServiceld () ) ; 

return "Hello World"; 

} 

e 在 feign-consumer 应 用 中 增加 上 文中 提 到 的 重 试 配置 参数 。 其 中 ， 
由 于 HELLOSERVICE.ribbon.MaxAutoRetries 设 置 为 1， 所 以 重 试 策略 先 
尝试 访问 首选 实例 一 次 ， 失 败 后 才 更 换 实例 访问 ， 而 更 换 实例 访问 的 次 
数 通 过 HELLO-SERVICE.ribbon.MaxAutoRetriesNextServer 参数 设置 为 
2， 所 以 会 尝试 更 换 两 次 实例 进行 重 试 。 

se 最后， 启动 这 些 应 用 ， 并 党 试 访问 儿 次 
http://localhost:9001/feignconsumer 接 口 。 当 请 求 发 生 超时 的 时 候 ， 我 们 
在 hello-service 的 控制 台中 可 能 会 获得 如 下 输出 内 容 (由 于 sleepTime 的 
随机 性 ， 并 不 一 定 每 次 相同 ) : 

INFO 19264---[nio-8001-exec-6]com.didispace.web.HelloController 
:SleepTime:2929 

INFO 19264---[nio-8001-exec-7]com.didispace.web.HelloController 
sleepTime:253 

INFO 19264---[nio-8001-exec-7]com.didispace.web.HelloController 
/hello,host: 

192.168.0.105,service id:hello-service 

INFO 19264---[nio-8001-exec-6]com.didispace.web.HelloController 
/hello,host: 

















192.168.0.105,service id:hello-service 

从 控制 台 输 出 中 ， 我 们 可 以 看 到 这 次 访问 的 第 一 次 请 求 延 迟 时 间 为 
2929 毫 秒 ， 由 于 超时 时 间 设 置 为 2000 毫 秒 ，Feign 客 户 端 发 起 了 重 试 ， 
第 二 次 请 求 的 延迟 为 253 秒 ， 没 有 超时 。Feign 客 户 端 在 进行 服务 调用 
时 ， 虽 然 经 历 了 一 次 失败 ， 但 是 通过 重 试 机 制 ， 最 终 还 是 获得 了 请 求 结 
果 。 所 以 ， 对 于 重 试 机 制 的 实现 ， 对 于 构建 高 可 用 的 服务 集群 来 说 非常 
重要 ， 而 Spring Cloud Feign 也 为 其 提供 了 足够 的 文 持 。 

这 里 需要 注意 一 点 ，Ribbon 的 超时 与 Hystrix 的 超时 是 两 个 概念 。 为 
了 让 上 述 实现 有 效 ， 我 们 需要 让 Hystrix 的 超时 时 间 大 于 Ribbon 的 超时 时 
间 ， 人 否则 Hystrix 命 令 超时 后 ， 该 命令 直接 熔断 ， 重 试 机 制 束 没有 任何 意 
> 

















Hystrix 配 站 





在 Spring Cloud Feign 中 ， 除 了 引入 了 用 于 客户 端 负 载 均 衡 的 Spring 
Cloud Ribbon 之 外 ， 还 引入 了 服务 保护 与 容错 的 工具 Hystrix。 默 认 情 况 
下 ，Spring Cloud Feign 会 为 将 所 有 Feign 客 户 端的 方法 都 封装 到 Hystrix 命 
令 中 进行 服务 保护 。 在 上 一 节 末 尾 ， 我 们 介绍 重 试 机 制 的 配置 时 ， 也 提 
到 了 关于 Hystrix 的 超时 时 间 配 置 。 那 么 在 本 节 中 ， 我 们 就 来 详细 介绍 一 
下 ， 如 何在 使 用 Spring Cloud Feign 时 配置 Hystrix 属 性 以 及 如 何 实现 服务 
降级 。 





对 于 Hystrix 的 全 局 配置 同 Spring Cloud Ribbon 的 全 局 配置 一 样 ， 直 接 
使 用 它 的 默认 配置 前 级 hystrix.command.default 就 可 以 进行 设置 ， 比 如 设 
置 全 局 的 超时 时 间 : 

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds 

另外 ， 在 对 Hystrix 进 行 配置 之 前 ， 我 们 需要 确认 feign.hystrix.enabled 
参数 没有 被 设置 为 false， 人 否则 该 参数 设置 会 关闭 Feign 客 户 端的 Hystrix 文 
持 。 而 对 于 我 们 之 前 测试 重 试 机 制 时 ， 对 于 Hystrix 的 超时 时 间 控 制 除 了 
可 以 使 用 上 面 的 配置 来 增加 熔断 超时 时 间 ， 也 可 以 通过 
feign.hystrix.enabled=false 来 关闭 Hystrix 功能 ， 或 者 使 用 
hystrix.command.default.execution.timeout.enabled=false 来 关闭 熔 断 功 
能 。 


禁用 Hystrix 


上 文 我 们 提 到 了 , 在 Spring Cloud Feign 中 ， 可 以 通过 
feign.hystrix.enabled=false 来 关闭 Hystrix 功 能 。 另 外 ， 如 果 不 想 全 局 地 关 
闭 Hystrix 文 持 ， 而 只 想 针 对 某 个 服务 客户 端 关 闭 Hystrix 文 持 时 ， 需 要 
通过 使 用 @Scope ("prototype") 注解 为 指定 的 客户 端 配置 Feign.Builder 
实例 ， 详 细 实 现 步 又 如 下 所 示 。 

e 构 建 一 个 关闭 Hystrix 的 配置 类 。 

Q@Configuration 

public class DisableHystrixConfiguration { 

(DBean 





@Scope ("prototype") 

public Feign.Builder feignBuilder () { 

return Feign.builder () ; 

} 

} 

e 在 HelloService 的 @FeignClient 注 解 中 ， 通 过 configuration 参 数 引 入 
上 面 实现 的 配置 。 

@FeignClient (name="HELLO- 
SERVICE",configuration=DisableHystrixConfiguration.class ) 

public interface HelloService { 


} 
指定 命令 配置 


对 于 Hystrix 命 令 的 配置 ， 在 实际 应 用 时 往往 也 会 根据 实际 业务 情况 
制定 出 不 同 的 配置 方案 。 配 置 方 法 也 跟 传统 的 Hystrix 命令 的 参数 配置 
相似 ， 采 用 hystrix.command.<commandKey> 作 为 前 级 。 而 
<commandKey> 默 认 情 况 下 会 采用 Feign 客 户 问 中 的 方法 名 作为 标识 ， 所 
以 ， 针 对 上 一 节 介 绍 的 尝试 机 制 中 对 /hello 接口 的 熔断 超时 时 间 的 配置 
可 以 通过 其 方法 名 作为 <commandKey> 来 进行 配置 ， 具 体 如 下 : 

hystrix.command.hello.execution.isolation.thread.timeoutInMilliseconds= 

在 使 用 指定 命令 配置 的 时 候 ， 需 要 注意 ， 由 于 方法 名 很 有 可 能 
复 ， 这 个 时 候 相 同方 法 名 的 Hystrix 配 置 会 共用 ， 所 以 在 进行 方法 定义 与 
配置 的 时 候 需 要 做 好 一 定 的 规划 。 当 然 ， 也 可 以 重 写 Feign.Builder 的 实 
现 ， 并 在 应 用 主 类 中 创建 它 的 实例 来 覆盖 自动 化 配置 的 
HystrixFeign.Builder 实 现 。 


服务 降级 配置 


Hystrix 提 供 的 服务 降级 是 服务 容错 的 重要 功能 ， 由 于 Spring Cloud 
Feign 在 定义 服务 客户 端的 时 候 与 Spring Cloud ”Ribbon 有 很 大 差别 ， 
HystrixCommand 定 义 被 封装 了 起 来 ， 我 们 无 法 像 之 前 介绍 Spring Cloud 
Hystrix 时 ， 通 过 @HystrixzCommand 注 解 的 fallback 参 数 那样 来 指定 具体 
的 服务 降级 处 理 方法 。 但 是 ，Spring Cloud Feign 提 供 了 另外 一 种 简单 的 
定义 方式 ， 下 面 我 们 在 之 前 创建 的 feign-consumer 工 程 中 进行 改造 。 

e 服 务 降级 逻辑 的 实现 只 需要 为 Feign 客 户 端的 定义 接口 编写 一 个 具 

















体 的 接口 实现 类 。 比 如 为 HelloService 接 口 实现 一 个 服务 降级 类 
HelloServiceFallback， 其 中 每 个 重 写 方法 的 实现 逻辑 都 可 以 用 来 定义 相 
应 的 服务 降级 逻辑 ， 具 体 如 下 : 

@Component 

public class HelloServiceFallback implements HelloService { 

(DOverride 

public String hello () { 

return "error"; 

} 

(DOverride 

public String hello (@RequestParam ("name") String name) { 

return "error"; 

} 

(DOverride 

public User hello (@RequestHeader ("name") String 
name,@RequestHeader ("age") 

Integer age) { 

return new User ("未 知 ",0) ; 

} 

(OOverride 

public String hello (@RequestBody User user) { 

return "error"; 


} 





} 

e 在 服务 绑 定 接口 HelloService 中 ， 通 过 @FeignClient 注 解 的 fallback 属 
性 来 指定 对 应 的 服务 降级 实现 类 。 

@FeignClient (name="HELLO- 
SERVICE",fallback=HelloServiceFallback.class ) 

public interface HelloService { 

@RequestMapping ("/hello") 

String hello (); 

@RequestMapping (value="/hellol",method=RequestMethod.GET) 

String hello (@RequestParam ("name") String name) ; 

@RequestMapping (value="/hello2",method=RequestMethod.GET) 

User hello (@RequestHeader ("name") String 
name,@RequestHeader ("age") Integer age) ; 

@RequestMapping (value="/hello3",method=RequestMethod.POST) 


String hello (@RequestBody User user) ; 

} 

测试 验证 

下 面 我 们 来 验证 一 下 服务 降级 逻辑 的 实现 。 启 动 服务 注册 中 心 和 
feign-consumer， 但 是 不 启动 ”hello-service 服务。 发送 GET 请求 到 
http://localhost:9001/feign-consumer2， 该 接口 会 分 别 调用 HelloService 中 
的 4 个 绑 定 接口 ， 但 因为 hello-service 服 务 没 有 启动 ， 会 直接 触发 服务 降 
级 ， 并 获得 下 面 的 输出 内 容 : 

error 

error 

name= 未 知 ，age=0 

error 

正如 我 们 在 HelloServiceFallback 类 中 实现 的 内 容 ， 每 一 个 服务 接口 的 
斯 路 器 实际 就 是 实现 类 中 的 重 写 函 数 的 实现 。 

注意 : 在 Brixton.SR5 版 本 中 ，fallback 的 实现 函数 中 不 再 支持 返回 
com.netflix.hystrix.HystrixCommand 和 rx.Observable 类 型 的 异步 执行 方 


式 和 啊 应 式 执行 方式 。 











Spring Cloud Feign 文 持 对 请 求 与 啊 应 进行 GZIP 压 缩 ， 以 减少 通信 过 
程 中 的 性 能 损耗 。 我 们 只 需 通 过 下 面 两 个 参数 设置 ， 就 能 开启 请 求 与 啊 
应 的 压缩 功能 : 

feign.compression.request.enabled=true 

feign.compression.response.enabled=true 

同时 ， 我 们 还 能 对 请 求 压 缩 做 一 些 更 细致 的 设置 ， 比 如 下 面 的 配置 
内 容 指定 了 压缩 的 请 求 数 据 类 型 ， 并 设置 了 请 求 压 缩 的 大 小 下 限 ， 只 有 
超过 这 个 大 小 的 请 求 才 会 对 其 进行 压缩 。 

feign.compression.request.enabled=true 

feign.compression.request.mime- 
types=text/xml,application/xml,application/json 

feign.compression.request.min-request-size=2048 

上 述 配 置 的 feign.compression.request.mime-types 和 
feign.compression.request.min-request-size 均 为 默认 值 。 


日 志 配 置 


Spring Cloud Feign 在 构建 被 @FeignClient 注 解 修饰 的 服务 客户 端 时 ， 
会 为 每 一 个 客户 端 都 创建 一 个 feign.Logger 实 例 ， 我 们 可 以 利用 该 日 志 对 
象 的 DEBUG 模 式 来 帮助 分 析 Feign 的 请 求 细节 。 可 以 在 
application.properties 文 件 中 使 用 logging.level.<FeignClient> 的 参数 配置 格 
式 来 开启 指定 Feign 客户 端的 DEBUG 上 日志， 其 中 <FeignClient> 为 Feign 
客户 端 定义 接口 的 完整 路 径 ， 比 如 针对 本 章 中 我 们 实现 的 HelloService 
可 以 按 如 下 配置 开启 : 

logging.level.com.didispace.web.HelloService=DEBUG 

但 是 ， 只 是 添加 了 如 上 配置 ， 还 无 法 实现 对 DEBUG 日 志 的 输出 。 
这 时 由 于 Feign 客户 端 默认 的 Logger.Level 对 象 定 义 为 NONE 级 别 ， 该 级 
别 不 会 记录 任何 Feign 调 用 过 程 中 的 信息 ， 所 以 我 们 需要 调整 它 的 级 
别 ， 针 对 全 局 的 日 志 级 别 ， 可 以 在 应 用 主 类 中 直接 加 入 Logger.Level 的 
Bean 创 建 ， 上 有 具体 如 下 : 

EnableFeignCjients 








@EnableDiscoveryCljlient 

SpringBootApplication 

public class ConsumerApplication { 

Bean 

Logger.Level feignLoggerLevel () { 

return Logger.Level.FULL; 

} 

public static void main (String[largs) { 
SpringApplication.run (ConsumerApplication.class,args) ; 





} 

当然 也 可 以 通过 实现 配置 类 ， 然 后 在 具体 的 Feign 客户 端 来 指定 配 
置 类 以 实现 是 人 否 要 调整 不 同 的 日 志 级 别 ， 比 如 下 面 的 实现 : 

@Configuration 

public class FullLogConfiguration { 

Bean 

Logger.Level feignLoggerLevel () { 

return Logger.Level.FULL; 

} 


} 

@FeignClient (name="HELLO- 
SERVICE",configuration=FullLogConfiguration.class) 

public interface HelloService { 





} 

在 调整 日 志 级 别 为 FULL 之 后 ， 我 们 可 以 再 访问 一 下 之 前 的 
http:/Wlocalhost:9001/feign-consumer 接 口 ， 这 时 我 们 在 feign-consumer 的 控 
制 台 中 束 可 以 看 到 类 似 下 面 的 请 求 详细 日 志 : 


对 于 Feign 的 Logger 级 别 主 要 有 下 面 4 类 ， 可 根据 实际 需要 进行 调整 使 
eNONE: 不 记录 任何 信息 。 
eBASIC: 仅 记 录 请 求 方法 、UREL 以 及 响应 状态 码 和 执行 时 间 。 
eHEADERS: 除了 记录 BASIC 级 别 的 信息 之 外 ， 还 会 记录 请 求 和 啊 

应 的 头 信 息 。 

pe 记录 所 有 请 求 与 响应 的 明细 ， 包 括 头 信息 、 请 求 体 、 元 数 











通过 前 几 章 的 介绍 ， 我 们 对 于 Spring Cloud Netflix 下 的 核心 组 件 已 经 
了 解 了 一 大 半 。 这 些 组 件 基 本 涵盖 了 微服 务 架 构 中 最 为 基础 的 几 个 核心 





设施 ， 利 用 这 些 组 件 我 们 已 经 可 以 构建 起 一 个 简单 的 微服 务 架 构 系 统 ， 
比如 ， 通 过 使 用 Spring Cloud Eureka 实 现 高 可 用 的 服务 注册 中 心 以 及 实 
现 微服 务 的 注册 与 发 现 ; 通过 Spring Cloud Ribbon 或 Feign 实 现 服务 间 负 
载 均 衡 的 接口 调用 ; 同时， 为 了 使 分 布 式 系统 更 为 健壮 ， 对 于 依赖 的 服 
务 调用 使 用 Spring Cloud Hystrix 来 进行 包装 ， 实 现 线程 隔离 并 加 入 熔断 
机 制 ， 以 避免 在 微服 务 架 构 中 因 个 别 服 务 出 现 异 常 而 引起 级 联 故 障 蔓 
延 。 通 过 上 述 思 路 ， 我 们 可 以 设计 出 类 似 下 图 的 基础 系统 架构 。 


在 该 架构 中 ， 我 们 的 服务 集群 包含 内 部 服务 Service A 和 Service 也 ， 
它们 都 会 癌 Eureka Server 集 群 进行 注册 与 订阅 服务 ， 而 Open Service 是 一 
个 对 外 的 RESTful API 服 务 ， 它 通过 F5、Nginx 等 网 络 设备 或 工具 软件 
实现 对 各 个 微服 务 的 路 由 与 负载 均衡 ， 并 公开 给 外 部 的 客户 端 调用 。 

在 本 间 中 ， 我 们 将 把 视线 聚焦 在 对 外 服务 这 块 内 容 ， 通 常 也 称 为 边 
缘 服务 。 首 先 需 要 肯定 的 是 ， 上 面 的 架构 实现 系统 功能 是 完全 没有 问题 
的 ， 但 是 我 们 还 是 可 以 进一步 思考 一 下 ， 这 样 的 架构 是 否 还 有 不 足 的 地 
方 会 使 运 维 人 员 或 开发 人 员 感 到 痛 否 。 

首先 ， 我 们 从 运 维 人 员 的 角度 来 看 看 ， 他 们 平时 都 需要 做 一 些 什么 
工作 来 文 持 这 样 的 架构 。 当 客户 端 应 用 单 击 茶 个 功能 的 时 候 往 往 会 发 出 
一 些 对 微服 务 获取 资源 的 请 求 到 后 端 ， 这 些 请 求 通过 F5、Nginx 等 设施 
的 路 由 和 负载 均衡 分 配 后 ， 被 转发 到 各 个 不 同 的 服务 实例 上 。 而 为 了 让 
这 些 设施 能 够 正确 路 由 与 分 发 请 求 ， 运 维 人 员 需 要 手工 维护 这 些 路 由 规 
则 与 服务 实例 列表 ， 汝 有 实例 增 减 或 是 卫 地 址 变动 等 情况 发 生 的 时 候 ， 
也 需要 手工 地 去 同步 修改 这 些 信息 以 保持 实例 信息 与 中 间 件 配置 内 容 的 
一 致 性 。 在 系统 规模 不 大 的 时 候 ， 维 护 这 些 信息 的 工作 还 不 会 太 过 复 
杂 ， 但 是 如 果 当 系统 规模 不 断 增 大 ， 那 么 这 些 看 似 简单 的 维护 任务 会 变 
得 越 来 越 难 ， 并 且 出 现 配置 错误 的 概率 也 会 逐渐 增加 。 很 显然 ， 这 样 的 
做 法 并 不 可 取 ， 所 以 我 们 需要 一 套 机 制 来 有 效 降低 维护 路 由 规则 与 服务 
实例 列表 的 难度 。 

其 次 ， 我 们 再 从 开发 人 员 的 角度 来 看 看 ， 在 这 样 的 架构 下 ， 会 产生 

















一 些 怎 样 的 问题 呢 ? 大 多 数 情 况 下 ， 为 了 保证 对 外 服务 的 安全 性 ， 我 们 
在 服务 端 实现 的 微服 务 接 口 ， 往 往 都 会 有 一 定 的 权限 校 验 机 制 ， 比 如 对 
用 户 登 录 状 态 的 校 验 等 ， 同 时 为 了 防止 客户 端 在 发 起 请 求 时 被 算 改 等 安 
全 方面 的 考虑 ， 还 会 有 一 些 签名 校 验 的 机 制 存 在 。 这 时 候 ， 由 于 使 用 了 
微服 务 架构 的 理念 ， 我 们 将 原本 处 于 一 个 应 用 中 的 多 个 模块 拆 成 了 多 个 
应 用 ,但 是 这 些 应 用 提供 的 接口 都 需要 这 些 校 验 逻 辑 ， 我 们 不 得 不 在 这 
些 应 用 中 都 实现 这 样 一 套 校 验 逻 辑 。 随 着 微服 务 规模 的 扩大 ， 这 些 校 验 
逻辑 的 见 余 变 得 越 来 越 多 ， 突 然 有 一 天 我 们 发 现 这 套 校 验 逻 辑 有 个 BUG 
需要 修复 ， 或 者 需要 对 其 做 一 些 扩 展 和 优化 ， 此 时 我 们 就 不 得 不 去 每 个 
应 用 里 修改 这 些 逻 辑 ， 而 这 样 的 修改 不 仅 会 引起 开发 人 员 的 抱怨 ， 更 会 
加 重 测试 人 员 的 负担 。 所 以 ， 我 们 也 需要 一 套 机 制 能 够 很 好 地 解决 微服 
务 架构 中 ， 对 于 微服 务 接口 访问 时 各 前 置 校 验 的 元 余 问 题 。 

为 了 解决 上 面 这 些 常 见 的 架构 问题 ，API 网 关 的 概念 应 运 而 生 。API 
网 关 是 一 个 更 为 智能 的 应 用 服务 器 ， 它 的 定义 类 似 于 面向 对 象 设 计 模 式 
中 的 Facade 模 式 ， 它 的 存在 就 像 是 整个 微服 务 架 构 系 统 的 门面 一 样 ， 所 
有 的 外 部 客户 端 访问 都 需要 经 过 它 来 进行 调度 和 过 滤 。 它 除了 要 实现 请 
求 路 由 、 负 载 均衡 、 校 验 过 滤 等 功能 之 外 ， 还 需要 更 多 能 力 ， 比 如 与 服 
人 
功能 。 

既然 API 网 关 对 于 微服 务 架 构 这 么 重要 ， 那 么 在 Spring Cloud 中 是 否 
有 相应 的 解决 方案 呢 ? 答案 是 很 肯定 的 ， 在 Spring “Cloud 中 了 提供 了 基 
于 Netflix Zuu 实 现 的 API 网 关 组 件 一 Spring Cloud Zuul。 那 么 ， 它 是 如 何 
解决 上 面 这 两 个 普遍 问题 的 呢 ? 

首先 ， 对 于 路 由 规则 与 服务 实例 的 维护 问题 。Spring Cloud Zuul 通 过 
与 Spring Cloud Eureka 进 行 整合 ， 将 自身 注册 为 Eureka 服 务 治理 下 的 应 
用 ， 同 时 从 Eureka 中 获得 了 所 有 其 他 微服 务 的 实例 信息 。 这 样 的 设计 非 
常 巧妙 地 将 服务 治理 体系 中 维护 的 实例 信息 利用 起 来 ， 使 得 将 维护 服务 
实例 的 工作 交 给 了 服务 治理 框架 上 自动 完成 ， 不 再 需要 人 工 介 入 。 而 对 于 
路 由 规则 的 维护 ，Zuu 默 认 会 将 通过 以 服务 名 作为 ContextPath 的 方式 来 
创建 路 由 映射 ， 大 部 分 情况 下 ， 这 样 的 默认 设置 已 经 可 以 实现 我 们 大 部 
分 的 路 由 需求 ， 除 了 一 些 特殊 情况 (比如 兼容 一 些 老 的 ”URL) 还 需要 
做 一 些 特别 的 配置 。 但 是 相 比 于 之 前 架构 下 的 运 维 工 作 量 ， 通 过 引入 
Spring Cloud Zuul 实 现 API 网 关 后 ， 己 经 能 够 大 大 减少 了 。 

其 次 ， 对 于 类 似 签 名 校 验 、 登 录 校 验 在 微服 务 架 构 中 的 见 余 问题 。 
理论 上 来 说 ， 这 些 校 验 逻 辑 在 本 质 上 与 微服 务 应 用 自身 的 业务 并 没有 多 
大 的 关系 ， 所 以 它们 完全 可 以 独立 成 一 个 单独 的 服务 存在 ， 只 是 它们 被 
剥离 和 独立 出 来 之 后 ， 并 不 是 给 各 个 微服 务 调 用 ， 而 是 在 API 网 关 服 务 
























































上 进行 统一 调用 来 对 微服 务 接口 做 前 置 过 滤 ， 以 实现 对 微服 务 接口 的 拦 
截 和 校 验 。Spring Cloud Zuu 提 供 了 一 套 过 滤器 机 制 ， 它 可 以 很 好 地 文 
持 这 样 的 任务 。 开 发 者 可 以 通过 使 用 Zuul 来 创建 各 种 校 验 过 滤 妖 ， 然 后 
虽 定 哪些 规则 的 请 求 需要 执行 校 验 馆 辑 ， 只 有 通过 校 验 的 才 会 被 路 由 到 
具体 的 微服 务 接口 ， 不 然 就 返回 错误 提示 。 通 过 这 样 的 改造 ， 各 个 业务 
层 的 微服 务 应 用 就 不 再 需要 非 业 务 性 质 的 校 验 逻 辑 了 ， 这 使 得 我 们 的 微 
服务 应 用 可 以 更 专注 于 业务 逻辑 的 开发 ， 同 时 微服 务 的 自动 化 测试 也 变 
得 更 容易 实现 。 

微服 务 架 构 虽 然 可 以 将 我 们 的 开发 单元 拆 分 得 更 为 细致 ， 有 效 降低 
了 开发 难度 ， 但 是 它 所 引出 的 各 种 问题 如 果 处 理 不 当 会 成 为 实施 过 程 中 
的 不 稳定 因素 ， 其 至 掩盖 挥 原 本 实施 微服 务 市 来 的 优势 。 所 以 ， 在 微服 
务 架构 的 实施 方案 中 ，API 网 关 服 务 的 使 用 几乎 成 为 了 必然 的 选择 。 

下 面 我 们 将 详细 介绍 Spring Cloud Zuul 的 使 用 方法 、 配 置 属性 以 及 一 
些 不 足 之 处 和 需要 进行 的 思考 。 
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介绍 了 这 么 多 关于 API 网 和 天 服务 的 概念 和 作用 ， 在 这 一 市 中 ， 我 们 不 
妨 用 实际 的 示例 来 直观 地 体验 一 下 Spring Cloud Zuul 中 封装 的 API 网 关 是 
如 何 使 用 和 运作 ， 并 应 用 到 微服 务 架构 中 去 的 。 


首先 ， 在 实现 各 种 API 网 关 服 务 的 高 级 功能 之 前 ， 我 们 需要 做 一 些 准 
备 工 作 ， 比 如 ， 构 建 起 最 基本 的 API 网 关 服 务 ， 并 且 搭 建 几 个 用 于 路 由 
和 过 滤 使 用 的 微服 务 应 用 等 。 对 于 微服 务 应 用 ， 我 们 可 以 直接 使 用 之 前 
章节 实现 的 hello-service 和 feign-consumer。 虽然 之 前 我 们 一 直 将 feign- 
consumer 视 为 消费 者 ， 但 是 在 Eureka 的 服务 注册 与 发 现 体 系 中 ， 每 个 服 
务 既 是 提供 者 也 是 消费 者 ， 所 以 feign-consumer 实质 上 也 是 一 个 服务 提 
供 者 。 之 前 我 们 访问 的 http://localhost:9001/feign-consumer 等 一 系列 接口 
就 是 它 提 供 的 服务 。 读 者 也 可 以 使 用 自己 实现 的 微服 务 应 用 ， 因 为 这 部 
分 不 是 本 章 的 重点 ， 任 何 微服 务 应 用 都 可 以 被 用 来 进行 后 续 的 试验 。 这 
里 ， 我 们 详细 介绍 一 下 API 网 关 服 务 的 构建 过 程 。 





e 创 建 一 个 基础 的 Spring Boot 工 程 ， 命 名 为 api-gateway， 并 在 
pom.xml 中 引入 spring-cloud-starter-zuul 依 赖 ， 有 具体 如 下 : 
<parent> 


<groupId>org.Springframework.boot</groupId> 
<artifactId>spring-boot-starter-parent</artifactId> 
<version>1.3.7.RELEASE</version> 
<relativePath/> 

</parent> 

<dependencies> 

<dependency> 
<groupId>org.Springframework.cloud</groupId> 
<artifactId>spring-cloud-starter-zuul</artifactId> 
</dependency> 

</dependencies> 

<dependencyManagement> 

<dependencies> 

<dependency> 


<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-dependencies</artifactId> 

<version>Brixton.SR5</version> 

<type>pom</type> 

<scope>import</scope> 

</dependency> 

</dependencies> 

</dependencyManagement> 

对 于 spring-cloud-starter-zuul 依 赖 ， 可 以 通过 查看 它 的 依赖 内 容 了 解 
到 : 该 模块 中 不 仅 包 含 了 Netflix Zuu 的 核心 依赖 zuul-core， 它 还 包含 了 
下 面 这 些 网 关 服 务 需 要 的 重要 依赖 。 

加 spring-cloud-starter-hystrix: 该 依赖 用 来 在 网 关 服 务 中 实现 对 微服 务 
转 及 时 候 的 保护 机 制 ， 通 过 线程 隔离 和 断路 磺 ， 防 止 微 服务 的 故障 引发 
API 网 天 资源 无 法 释放 ， 从 而 影响 其 他 应 用 的 对 外 服务 。 

nr ribbon: 该 依赖 用 来 实现 在 网 关 服 务 进行 路 由 转 
发 时 候 的 客户 端 负 载 均衡 以 及 请 求 重 试 。 

加 spring-boot-starter-actuator: 该 依赖 用 来 提供 常规 的 微 服务 管理 端 
点 。 另 外 ， 在 Spring Cloud Zuu 中 还 特别 提供 了 Aroutes 端 点 来 返回 当前 
的 所 有 路 由 规则 。 

e 创 建 应 用 主 类 ， 使 用 @EnableZuulProxy 注 解 开启 Zuul 的 API 网 关 服 
务 功能 。 

@EnableZuulProxy 

SpringCloudApplication 

public class Application { 

public static void main 〈String[]args) { 

new 
SpringApplicationBuilder (Application.class) .web (true) .run Cargs) ; 


} 

e 在 application.properties 中 配置 Zuul 应 用 的 基础 信息 ， 如 应 用 名 、 服 
务 端口 号 等 ， 具 体内 容 如 下 : 

spring.application.name=api-gateway 

server.port=5555 


完成 上 面 的 工作 后 ， 通 过 Zuul 实 现 的 API 网 关 服 务 就 构建 完毕 了 。 
请 求 路 由 


下 面 ， 我 们 将 通过 一 个 简单 的 示例 来 为 上 面 构建 的 网 关 服 务 增 加 请 
求 路 由 的 功能 。 为 了 演示 请 求 路 由 的 功能 ， 我 们 先 将 之 前 准备 的 Eureka 
服务 注册 中 心 和 微服 务 应 用 都 局 动 起 来 。 此 时 ， 我 们 在 Eureka 信 息 面 板 
中 可 以 看 到 如 下 图 所 示 的 两 个 微服 务 应 用 已 经 被 注册 成 功 了 。 


传统 路 由 方式 

使 用 Spring Cloud Zuul 实 现 路 由 功能 非常 简单 ， 只 需要 对 api-gateway 
0 由 规则 的 配置 ， 束 能 实现 传统 的 路 由 转发 功能 ， 比 

0: 

zuul.routes.api-a-url.path=/api-a-url/** 

zuul.routes.api-a-url.url=http://localhost:8080/ 

该 配置 定义 了 发 往 API 网 关 服 务 的 请 求 中 ， 所 有 符合 /api-a-url/** 规 
则 的 访问 都 将 被 路 由 转发 到 http:/Wlocalhost:8080/ 地 址 上， 也 就 是 说 ， 当 
我 们 访问 http://localhost:5555/api-a-url/hello 的 时 候 ，API 网 关 服 务 会 将 该 
请 求 路 由 到 http://localhost:8080/hello 提供 的 微服 务 接口 上 。 其 中 ， 配 置 
属性 zuulroutes.api-a-url.path 中 的 api-a-url 部 分 为 路 由 的 名 字 ， 可 以 任意 
定义 ， 但 是 一 组 path 和 url 映 射 关系 的 路 由 名 要 相同 ， 下 面 将 要 介绍 的 面 
各 服务 的 映射 方式 也 是 如 此 。 

面 癌 服务 的 路 由 

很 显然 ， 传 统 路 由 的 配置 方式 对 于 我 们 来 说 并 不 友好 ， 它 同样 需要 
运 维 人 员 花 费 大 量 的 时 间 来 维护 各 个 路 由 path 与 url 的 关系 。 为 了 解雇 这 
个 问题 ，Spring Cloud Zuul 实 现 了 与 Spring Cloud Eureka 的 无 颖 整合 ， 我 
们 可 以 让 路 由 的 path 不 是 映射 具体 的 ul， 而 是 让 它 映 射 到 某 个 具体 的 服 
务 ， 而 具体 的 url 则 交 给 Eureka 的 服务 发 现 机 制 去 自动 维护 ， 我 们 称 这 类 
路 由 为 面向 服务 的 路 由 。 在 Zuul 中 使 用 服务 路 由 也 同样 简单 ， 只 需 做 下 
面 这 些 配 置 。 

e 为 了 与 Eureka 整合 ， 我 们 需要 在 api-gateway 的 pom.xml 中 引入 
springcloud-starter-eureka 依 赖 ， 具 体 如 下 : 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-eureka</artifactId> 

</dependency> 

e 在 api-gateway 的 application.properties 配 置 文件 中 指定 Eureka 注 册 中 
心 的 位 置 ， 并 且 配 置 服务 路 由 。 有 具体 如 下 : 

zuul.routes.api-a.path=/api-a/** 

zuul.routes.api-a.serviceld=hello-service 

zuul.routes.api-b.path=/api-b/** 








zuul.routes.api-b.serviceld=feign-consumer 

eureka.client.serviceUTrl.defaultZone=http://localhost:1111/eureka/ 

针对 我 们 之 前 准备 的 两 个 微服 务 应 用 hello-service 和 feign-consumer， 
在 上 面 的 配置 中 分 别 定义 了 两 个 名 为 api-a 和 api-b 的 路 由 来 映射 它们 。 
另外 ， 通 过 指定 Eureka Server 服 务 注 册 中 心 的 位 置 ， 除 了 将 自己 注册 成 
服务 之 外 ， 同 时 也 让 Zuul 能 够 获取 hello-service 和 feign-consumer 服 务 的 
实例 清单 ， 以 实现 path 映 射 服务 ， 再 从 服务 中 挑选 实例 来 进行 请 求 转发 
的 完整 路 由 机 制 。 

在 完成 了 上 面 的 服务 路 由 配置 之 后 ， 我 们 可 以 将 eureka-server、 
hello-service、feign-consumer 以 及 这 里 用 Spring ”Cloud ”Zuul 构 建 的 api- 
gateway 都 启动 起 来 。 局 动 完毕 ， 在 eureka-server 的 信息 面板 中 ， 我 们 
可 以 看 到 ， 除 了 hello-service 和 feign-consumer 之 外 ， 多 了 一 个 网 关 服 务 
API-GCATEWAY 。 


通过 上 面 的 搭建 工作 ， 我 们 已 经 可 以 通过 服务 网 关 来 访问 hello- 
service “和 feign-consumer 这 两 个 服务 了 。 根 据 配置 的 映射 关系 ， 分 别 回 
网 关 发 起 下 面 这 些 请 求 。 

ehttp://localhost:5555/api-a/hello: 该 url 符合 /api-a/#**x 规 则 ， 由 api-a 路 
由 负责 转发 ， 该 路 由 映射 的 serviceId 为 hello-service， 所 以 最 终 /hello 请 求 
会 被 发 送 到 hello-service 服 务 的 某 个 实例 上 去 。 

ehttp://localhost:5555/api-b/feign-consumer: 该 rl 符合/api-b/** 规 则 ， 
由 api-b 路 由 负责 转发 ， 访 路 由 映射 的 serviceId 为 feign-consumer， 上 所 以 最 
终 /feign-consumer 请 求 会 被 发 送 到 feign-consumer 服 务 的 某 个 实例 上 去 。 

通过 面 问 服务 的 路 由 配置 方式 ， 我 们 不 需要 再 为 各 个 路 由 维护 微服 
务 应 用 的 具体 实例 的 位 置 ， 而 是 通过 简单 的 path 与 serviceld 的 映射 组 
合 ， 使 得 维护 工作 变 得 非常 简单 。 这 完全 归功 于 Spring Cloud Eureka 的 
服务 发 现 机 制 ， 它 使 得 API 网 关 服 务 可 以 自动 化 完成 服务 实例 清单 的 维 
护 ， 完 美 地 解决 了 对 路 由 映射 实例 的 维护 问题 。 


和 By 
请 求 过 渡 
JD 





在 实现 了 请 求 路 由 功能 之 后 ， 我 们 的 微服 务 应 用 提供 的 接口 就 可 以 
通过 统一 的 API 网 关 入 口 被 客户 端 访问 到 了 。 但 是 ， 每 个 客户 端 用 户 请 
求 微服 务 应 用 提供 的 接口 时 ， 它 们 的 访问 权限 往往 都 有 一 定 的 限制 ， 系 
统 并 不 会 将 所 有 的 微服 务 接口 都 对 它们 开放 。 然 而 ， 目 前 的 服务 路 由 并 
没有 限制 权限 这 样 的 功能 ， 所 有 请 求 都 会 被 坚 无 保留 地 转发 到 具体 的 应 
用 并 返回 结果 ， 为 了 实现 对 客户 端 请 求 的 安全 校 验 和 权限 控制 ， 最 简单 








和 粗 雄 的 方法 就 是 为 每 个 微服 务 应 用 都 实现 一 套用 于 校 验 签名 和 鉴别 权 
限 的 过 滤 占 或 拦截 器 。 不 过 ， 这 样 的 做 法 并 不 可 取 ， 它 会 增加 日 后 系统 
的 维护 难度 ， 因 为 同一 个 系统 中 的 各 种 校 验 逻 辑 很 多 情况 下 都 是 大 致 相 
同 或 类 似 的 ， 这 样 的 实现 方式 会 使 得 相似 的 校 验 逻辑 代码 被 分 散 到 了 各 
个 微服 务 中 去 ， 元 余 代 人 码 的 出 现 是 我 们 不 希望 看 到 的 。 所 以 ， 比 较 好 的 
做 法 是 将 这 些 校 验 逻 辑 剥 离 出 去 ， 构 建 出 一 个 独立 的 鉴 权 服务 。 在 完成 
了 和 剥离 之 后 ， 有 不 少 开 发 者 会 直接 在 微服 务 应 用 中 通过 调用 鉴 权 服务 来 
实现 校 验 ， 但 是 这 样 的 做 法 仅 仪 只 是 解决 了 鉴 权 逻辑 的 分 离 ， 并 没有 在 
本 质 上 将 这 部 分 不 属于 元 余 的 逻辑 从 原 有 的 微服 务 应 用 中 拆 分 出 ， 元 余 
的 拦截 器 或 过 滤器 依然 会 存在 。 

对 于 这 样 的 问题 ， 更 好 的 做 法 是 通过 前 置 的 网 关 服 务 来 完成 这 些 非 
业务 性 质 的 校 验 。 由 于 网 关 服 务 的 加 入 ， 外 部 客户 端 访问 我 们 的 系统 已 
经 有 了 统一 入 口 ， 既 然 这 些 校 验 与 具体 业务 无 天 ， 那 何不 在 请 求 到 达 的 
时 候 就 完成 校 验 和 过 滤 ， 而 不 是 转发 后 再 过 滤 而 导致 更 长 的 请 求 延 迟 。 
同时 ， 通 过 在 网 关中 完成 校 验 和 过 滤 ， 微 服务 应 用 端 承 可 以 去 除 各 种 复 
杂 的 过 滤器 和 拦截 器 了 ， 这 使 得 微服 务 应 用 接口 的 开发 和 测试 复杂 上 度 也 
得 到 了 相应 降低 。 

为 了 在 API 网 关中 实现 对 客户 端 请 求 的 校 验 ， 我 们 将 继续 介绍 Spring 
Cloud Zuul 的 另外 一 个 核心 功能 : 请 求 过 滤 。Zuu 人 允许 开发 者 在 API 网 关 
上 通过 定义 过 滤器 来 实现 对 请 求 的 拦截 与 过 滤 ， 实 现 的 方法 非常 简单 ， 
我 们 只 需要 继承 ZuulFilter 抽 象 类 并 实现 它 定 义 的 4 个 抽象 函数 就 可 以 完 
成 对 请 求 的 拦截 和 过 滤 了 。 

下 面 的 代码 定义 了 一 个 简单 的 Zuul 过 滤器 ， 它 实现 了 在 请 求 被 路 由 
之 前 检查 HttpServletRequest 中 是 否 有 accessToken 参 数 ， 若 有 就 进行 路 
由 ， 告 没有 就 拒绝 访问 ， 返 回 401 Unauthorized 错 误 。 

public class AccessFilter extends ZuulFilter { 





























private static Logger 
log=LoggerFactory.getLogger (AccessFilter.class) ; 
(DOverride 


public String filterType () { 
return "pre"; 

} 

(DOverride 

public int filterOrder () { 
return 0; 

} 

(DOverride 


public boolean shouldFilter () { 

return true; 

} 

(DOverride 

public Object run () { 

RequestContext ctx=RequestContext.getCurrentContext (); 
HttpServletRequest request=ctx.getRequest 〈) ; 

log.info ("send {} request to {}",request.getMethod 〈) ， 
request.getRequestURL () .toString () ) ; 

Object accessToken=request.getParameter 〈"accessToken'" ) ; 
if (accessToken==null) { 

log.warn ("access token is empty") ; 
ctx.setSendZuulResponse (false) ; 
ctx.setResponseStatusCode (401) ; 

return null; 

log.info ("access token ok" ) ; 

return null; 

} 

} 


} 

在 上 面 实现 的 过 滤器 代码 中 ， 我 们 通过 继承 ZuulFilter 抽 象 类 并 重 写 
下 面 4 个 方法 来 实现 自 定义 的 过 滤器 。 这 4 个 方法 分 别 定义 了 如 下 内 容 。 

efilterType: 过 滤器 的 类 型 ， 它 决定 过 滤器 在 请 求 的 哪个 生命 周期 中 
执行 。 这 里 定义 为 pre， 代 表 会 在 请 求 被 路 由 之 前 执行 。 

efilterOrder: 过 滤器 的 执行 顺序 。 当 请 求 在 一 个 阶段 中 存在 多 个 过 
滤器 时 ， 需 要 根据 该 方法 返回 的 值 来 依次 执行 。 

eshouldFilter: 判断 该 过 滤器 是 否 需要 被 执行 。 这 里 我 们 直接 返回 了 
true， 因 此 该 过 滤器 对 所 有 请 求 都 会 生效 。 实 际 运用 中 我 们 可 以 利用 该 
函数 来 指定 过 滤器 的 有 效 范 围 。 

erun: 过 滤器 的 具体 逻辑 。 这 里 我 们 通过 
ctx.SetSendZuulResponse (false) 令 zuul 过 滤 该 请 求 ， 不 对 其 进行 路 
由 ， 然 后 通过 ”ctx.setResponseStatusCode (401) 设置 了 其 返回 的 错误 
码 ， 当 然 也 可 以 进一步 优化 我 们 的 返回 ， 比 如 ， 通 过 
ctx.setResponseBody (body) 对 返回 的 body 内 容 进 行 编辑 等 。 

在 实现 了 自 定 义 过 小 器 之 后 ， 它 并 不 会 直接 生效 ， 我 们 还 需要 为 其 
创建 具体 的 ”Bean 才 能 启动 该 过 滤器 ， 比 如 ， 在 应 用 主 类 中 增加 如 下 内 


od 


合 : 








@EnableZuulProxy 
SpringCloudApplication 
public class Application { 
public static void main (String[largs) { 
new 
SpringApplicationBuilder (Application.class) .web (true) .run (Cargs) ; 
} 


Bean 

public AccessFilter accessFilter () { 

return new AccessFilter () ; 

} 

} 

在 对 api-gateway 服 务 完成 了 上 面 的 改造 之 后 ， 我 们 可 以 重新 启动 
它 ， 并 发 起 下 面 的 请 求 ， 对 上 面 定 义 的 过 滤器 做 一 个 验证 。 

ehttp://localhost:5555/api-a/hello: 返回 401 错 误 。 

ehttp://localhost:5555/api-a/hello&accessToken=token: 正确 路 由 到 
hello-service 的 /hello 接 口 ， 并 返回 Hello World。 

到 这 里 ， 对 于 API 网 和 天 服 务 的 快速 入 门 示例 就 完成 了 。 通 过 对 Spring 
Cloud Zuul 两 个 核心 功能 的 介绍 ， 相 信 读 者 已 经 能 够 体会 到 API 网 关 服 务 
对 微服 务 架构 的 重要 性 了 ， 惑 目前 掌握 的 API 网 关 知 识 ， 我 们 可 以 将 具 
体 原 因 总 结 如 下 : 

e 它 作为 系统 的 统一 入 口 ， 屏 丽 了 系统 内 部 各 个 微服 务 的 细节 。 

e 它 可 以 与 服务 治理 框架 结合 ， 实 现 自动 化 的 服务 实例 维护 以 及 负载 
均衡 的 路 由 转发 。 

e 它 可 以 实现 接口 权限 校 验 与 微服 务 业务 逻辑 的 解 耘 。 

e 通 过 服务 网 关中 的 过 滤器 ， 在 各 生命 周期 中 去 校 验 请 求 的 内 容 ， 将 
原本 在 对 外 服务 层 做 的 校 验 前 移 ， 保 证 了 微服 务 的 无 状态 性 ， 同 时 降低 
了 微服 务 的 测试 难度 ， 让 服务 本 号 更 集中 关注 业务 逻辑 的 处 理 。 

实际 上 ， 基 于 Spring Cloud Zuul 实 现 的 API 网 关 服 务 除了 上 面 所 示 的 
优点 之 外 ， 它 还 有 一 些 更 加 强大 的 功能 ， 我 们 将 在 后 续 的 章 市 对 其 进行 
更 深入 的 介绍 。 通 过 本 节 的 内 容 ， 我 们 只 是 希望 以 一 个 简单 的 例子 币 领 
读者 先 来 简单 认识 一 下 API 网 关 服 务 提供 的 基础 功能 以 及 它 在 微服 务 架 
构 中 的 重要 地 位 。 
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在 “快速 入 门 ”一 节 的 请 求 路 由 示例 中 ， 我 们 对 Spring Cloud Zuul 中 的 
两 类 路 由 功能 已 经 做 了 简单 的 使 用 介绍 。 在 本 节 中 ， 我 们 将 进一步 详细 
介绍 关于 Spring Cloud Zuul 的 路 由 功能 ， 以 帮助 读者 更 好 地 理解 和 使 用 
全， 


统 星 


所 谓 的 传统 路 由 配置 方式 就 是 在 不 依赖 于 服务 发 现 机 制 的 情况 下 ， 
通过 在 配置 文件 中 具体 指定 每 个 路 由 表达 式 与 服务 实例 的 映射 关系 来 实 
现 API 网 关 对 外 部 请 求 的 路 由 。 

没有 Eureka 等 服务 治理 框架 的 帮助 ， 我 们 需要 根据 服务 实例 的 数量 
采用 不 同方 式 的 配置 来 实现 路 由 规则 。 

e 单 实例 配置 : 通过 zuul.routes.<route>.path 与 zuul.routes.<route>.url 
参数 对 的 方式 进行 配置 ， 比 如 : 

zuul.routes.user-service.path=/user-service/** 

zuul.routes.user-service.url=http://localhost:8080/ 

该 配置 实现 了 对 符合 /user-service/** 规 则 的 请 求 路 径 转 发 到 
http:/localhost:8080/ 地 址 的 路 由 规则 。 比 如 ， 当 有 一 个 请 求 
http://localhost:5555/user-service/hello 被 发 送 到 API 网 关上 ， 由 于 /user- 
service/hello 能 够 被 上 述 配 置 的 path 规则 匹配 ， 所 以 API 网 关 会 转发 请 
求 到 http://localhost:8080/hello 地 址 。 

e 多 实例 配置 : 通过 zuul.routes.<route>.path 与 zuul.routes. 
<route>.serviceld 参 数 对 的 方式 进行 配置 ， 比 如 : 

zuul.routes.user-service.path=/user-service/** 

zuul.routes.user-service.serviceld=user-service 
ribbon.eureka.enabled=false 

USerT- 
service.ribbon.listOfServers=http://localhost:8080/,http://localhost:8081/ 

该 配置 实现 了 对 符合 /user-service/** 规则 的 请 求 路 径 转 发 到 
http://localhost:8080/ 和 http://localhost:8081/ 两 个 实例 地 址 的 路 由 规则 。 它 
的 配置 方式 与 服务 路 由 的 配置 方式 一 样 ， 都 采用 了 ea routes. 
<route>.path 与 zuul.routes.<route>. 0 的 映射 方式 ， 只 是 这 里 
的 serviceId 是 由 用 户 手 工 命名 的 服务 名 称 ， 配 合 ribbon.listOfServers 参数 











实现 服务 与 实例 的 维护 。 由 于 存在 多 个 实例 ，API 网 关 在 进行 路 由 转发 
时 需要 实现 负载 均衡 策略 ， 于 是 这 里 还 需要 Spring Cloud Ribbon 的 配 
合 。 由 于 在 Spring Cloud Zuul 中 自 带 了 对 Ribbon 的 依赖 ， 所 以 我 们 只 需 
做 一 些 配 置 即 可 ， 比 如 上 面 示例 中 关于 Ribbon 的 各 个 配置 ， 它 们 的 具体 
作用 如 下 所 示 。 

ribbon.eureka.enabled: 由 于 zuul.routes.<route>.serviceId 指定 的 是 
服务 名 称 ， 默 认 情 况 下 Ribbon 会 根据 服务 发 现 机 制 来 获取 配置 服务 名 
对 应 的 实例 清单 。 但 是 ， 该 示例 并 没有 整合 类 似 Eureka 之 类 的 服务 治 
理 框架 ， 所 以 需要 将 该 参数 设置 为 false， 和 否则 配置 的 serviceId 获 取 不 到 
对 应 实例 的 清单 。 

国 USer-SerVice.Tribbon.listOfServers: 该 参数 内 容 与 zuul.routes. 
<route>.serviceld 的 配置 相对 应 ， 开 头 的 user-service 对 应 了 serviceId 的 
J 内 部 手工 维护 了 服务 与 实例 的 对 
以 大 人 处。 

不 论 是 单 实例 还 是 多 实例 的 配置 方式 ， 我 们 都 需要 为 每 一 对 映射 关 
系 指 定 一 个 名 称 ， 也 就 是 上 面 配置 中 的 <route>， 每 一 个 <route> 对 应 了 
一 条 路 由 规则 。 每 条 路 由 规则 都 需要 通过 path 属性 来 定义 一 个 用 来 匹 
配 客 户 端 请 求 的 路 径 表 达 式 ， 并 通过 url 或 serviceId 属 性 来 指定 请 求 表 
达 式 映射 具体 实例 地 址 或 服务 名 。 


服务 路 由 配置 


对 于 服务 路 由 ， 我 们 在 快速 入 门 示 例 中 已 经 有 过 基础 的 介绍 和 体 
验 ，Spring Cloud Zuul 通 过 与 Spring Cloud Eureka 的 整合 ， 实 现 了 对 服务 
实例 的 自动 化 维护 ， 所 以 在 使 用 服务 路 由 配置 的 时 候 ， 我 们 不 需要 癌 传 
统 路 由 配置 方式 那样 为 serviceId 指 定 具 体 的 服务 实例 地 址 ， 只 需要 通过 
zuul.routes.<route>.path 与 zuul.routes.<route>.serviceld 参 数 对 的 方式 进行 
配置 即 可 。 

比如 下 面 的 示例 ， 它 实现 了 对 符合 /user-service/** 规 则 的 请 求 路 径 转 
发 到 名 为 user-service 的 服务 实例 上 去 的 路 由 规则 。 其 中 <route> 可 以 指定 
为 任意 的 路 由 名 称 。 

zuul.routes.user-service.path=/user-service/** 

zuul.routes.user-service.serviceld=user-service 

对 于 面向 服务 的 路 由 配置 ， 除 了 使 用 path 与 serviceId 了 映射 的 配置 方式 
之 外 ， 还 有 一 种 更 简洁 的 配置 方式 : zuul.routes.<serviceId>=<path>， 其 
中 <serviceId> 用 来 指定 路 由 的 具体 服务 名 ，<path> 用 来 配置 匹配 的 请 求 
表达 式 。 比 如 下 面 的 例子 ， 它 的 路 由 规则 等 价 于 上 面 通过 path 与 

















serviceId 组 合 使 用 的 配置 方式 。 

zuul.routes.user-service=/user-service/** 

传统 路 由 的 映射 方式 比较 直观 且 容 易 理解 ，API 网 关 直 接 根据 请 求 的 
UREL 路 径 找 到 最 匹配 的 path 表 达 式 ， 直 接 转发 给 该 表达 式 对 应 的 ur 或 对 
应 serviceId 下 配置 的 实例 地 址 ， 以 实现 外 部 请 求 的 路 由 。 那 么 当 采 用 
path 与 serviceId 以 服务 路 由 的 方式 实现 时 ， 在 没有 配置 任何 实例 地 址 的 
情况 下 ， 外 部 请 求 经 过 API 网 关 的 时 候 ， 它 是 如 何 被 解析 并 转发 到 服务 
具体 实例 的 呢 ? 

在 本 章 一 开始 ， 我 们 就 提 到 了 Zuul 巧妙 地 整合 了 Eureka 来 实现 面 
回 服 务 的 路 由 。 实 际 上 ， 我 们 可 以 直接 将 API 网 关 也 看 作 Eureka 服 务 治 
理 下 的 一 个 普通 微服 务 应 用 。 它 除了 会 将 自己 注册 到 Eureka 服 务 注 册 中 
心 上 之 外 ， 也 会 从 注册 中 心 获 取 所 有 服务 以 及 它们 的 实例 清单 。 所 以 ， 
在 Eureka 的 帮助 下 ，API 网 关 服 务 本 喘 束 已 经 维护 了 系统 中 所 有 serviceId 
与 实例 地 址 的 映射 关系 。 当 有 外 部 请 求 到 达 API 网 关 的 时 候 ， 根 据 请 求 
的 URL 路 径 找到 最 佳 匹 配 的 path 规 则 ，API 网 关 束 可 以 知道 要 将 该 请 求 
路 由 到 哪个 具体 的 serviceId 上 去 。 由 于 在 API 网 关中 已 经 知道 serviceId 对 
应 服务 实例 的 地 址 清单 ， 那 么 只 需要 通过 Ribbon 的 负载 均衡 策略 ， 直 接 
在 这 些 清单 中 选择 一 个 具体 的 实例 进行 转发 就 能 完成 路 由 工作 了 。 


芝 是 ES 








虽然 通过 Eureka 与 Zuul 的 整合 已 经 为 我 们 省 去 了 维护 服务 实例 清单 
的 大 量 配置 工作 ， 剩 下 只 需要 再 维护 请 求 路 径 的 匹配 表达 式 与 服务 名 的 
贞 射 关系 即 可 。 但 是 在 实际 的 运用 过 程 中 会 发 现 ， 大 部 分 的 路 由 配置 规 
则 几乎 都 会 采用 服务 名 作为 外 部 请 求 的 前 级 ， 比 如 下 面 的 例子 ， 其 中 
path ”路 径 的 前 缀 使 用 了 ”user-service， 而 对 应 的 服务 名 称 也 是 user- 
service。 

zuul.routes.user-service.path=/user-service/** 

zuul.routes.user-service.serviceld=user-service 

对 于 这 样 具有 规则 性 的 配置 内 容 ， 我 们 总 是 希望 可 以 自动 化 地 完 
成 。 非 常 庆 季 ，Zuu 默 认 实 现 了 这 样 的 贴心 功能 ， 当 我 们 为 Spring 
Cloud Zuul 构 建 的 API 网 关 服 务 引 入 Spring Cloud Eureka 之 后 ， 它 为 
Eureka 中 的 每 个 服务 都 自动 创建 一 个 默认 路 由 规则 ， 这 些 默认 规则 的 
path 会 使 用 serviceId 配 置 的 服务 名 作为 请 求 前 级 ， 束 如 上 面 的 例子 那 


样 
由 于 默认 情况 下 所 有 Eureka 上 的 服务 都 会 被 Zuul 上 自动 地 创建 映射 
关系 来 进行 路 由 ， 这 会 使 得 一 些 我 们 不 希望 对 外 开放 的 服务 也 可 能 被 外 











部 访问 到 。 这 个 时 候 ， 我 们 可 以 使 用 zuul.ignored-services 参数 来 设置 一 
个 服务 名 匹配 表达 式 来 定义 不 自动 创建 路 由 的 规则。Zuul 在 自动 创建 服 
务 路 由 的 时 候 会 根据 该 表达 式 来 进行 判断 ， 如 果 服 务 名 匹配 表达 式 ， 那 
么 Zuul 将 跳 过 该 服务 ， 不 为 其 创建 路 由 规则 。 比 如 ， 设 置 为 
zuul.ignored-services=* 的 时 候 ，Zuul 将 对 所 有 的 服务 都 不 自动 创建 路 由 
规则 。 在 这 种 情况 下 ， 我 们 就 要 在 配置 文件 中 逐个 为 需要 路 由 的 服务 添 
加 映射 规则 (可 以 使 用 path 与 serviceId 组 合 的 配置 方式 ， 也 可 使 用 更 简 
洛 的 zuulroutes.<serviceId>=<path> 配 置 方式 ) ， 只 有 在 配置 文件 中 出 现 
的 映射 规则 会 被 创建 路 由 ， 而 从 Eureka 中 获取 的 其 他 服务 ，Zuul 将 不 会 

再 为 它们 创建 路 由 规则 。 


定义 路 由 上 映射 规 见 





我 们 在 构建 微服 务 系 统 进行 业务 逻辑 开发 的 时 候 ， 为 了 兼容 外 部 不 
同 版 本 的 客户 端 程序 〈 尽 量 不 强迫 用 户 升级 客户 端 ) ， 一 般 都 会 采用 开 
闭 原 则 来 进行 设计 与 开发 。 这 使 得 系统 在 迭代 过 程 中 ， 有 时 候 会 需要 我 
们 为 一 组 互相 配合 的 微服 务 定义 一 个 版 本 标识 来 方便 管理 它们 的 版 本 关 
系 ， 根 据 这 个 标识 我 们 可 以 很 容易 地 知道 这 些 服务 需要 一 起 启动 并 配合 
使 用 。 比 如 可 以 采用 类 似 这 样 的 命名 : userservice-v1、userservice-v2、 
orderservice-v1、orderservice-vV2。 默 认 情 况 下 ，Zuul 上 自动 为 服务 创建 的 
路 由 表达 式 会 采用 服务 名 作为 前 经， 比如 针对 上 面 的 userservice-v1 和 
Userservice-vV2， 它 会 产生 /userservice-v1 和 /userservice-v2 两 个 路 径 表 达 式 
来 映射 ， 但 是 这 样 生成 出 来 的 表达 式 规则 较为 单一 ， 不 利于 通过 路 径 规 
则 来 进行 管理 。 通 常 的 做 法 是 为 这 些 不 同 版 本 的 微服 务 应 用 生成 以 版 本 
代号 作为 路 由 前 级 定义 的 路 由 规则 ， 比 如 /vl/userservice/。 这 时 候 ， 通 
过 这 样 具有 版 本 号 前 级 的 URL 路 人 径 ， 我 们 束 可 以 很 容易 地 通过 路 径 表 达 
式 来 归 类 和 管理 这 些 具 有 版 本 信息 的 微服 务 了 。 

针对 上 面 所 述 的 需求 ， 如 果 我 们 的 各 个 微服 务 应 用 都 遵循 了 类 似 
userservice-v1 这 样 的 命名 规则 ， 通 过 -分 隔 的 规范 来 定义 服务 名 和 服务 版 
本 标识 的 话 ， 那 么 ， 我 们 可 以 使 用 Zuul 中 自 定义 服务 与 路 由 映射 关系 的 
功能 ， 来 实现 为 符合 上 述 规则 的 微服 务 自 动 化 地 创建 类 
似 /Vl/userservice/** 的 路 由 匹配 规划 。 实 现 步 又 非常 简单 ， 只 需 在 ”API 
网 关 程 序 中 ， 增 加 如 下 Bean 的 创建 即 可 : 

(@Bean 

public PatternServiceRouteMapper serviceRouteMapper () { 

return new PatternServiceRouteMapper 

" (? <name>A^A.+) - (? <version>v.+$) ", 














"${version}H/${name}") ; 

} 

PatternServiceRouteMapper 对 象 可 以 让 开发 者 通过 正则 表达 式 来 自 定 
义 服 务 与 路 由 映射 的 生成 关系 。 其 中 构造 函数 的 第 一 个 参数 是 用 来 匹配 
服务 名 称 是 否 符 合 该 自 定义 规则 的 正则 表达 式 ， 而 第 二 个 参数 则 是 定义 
根据 服务 名 中 定义 的 内 容 转换 出 的 路 径 表 达 式 规则 。 当 开发 者 在 API 网 
关中 定义 了 PatternServiceRouteMapper 实 现 之 后 ， 只 要 符合 第 一 个 参数 
定义 规则 的 服务 名 ， 都 会 优先 使 用 该 实现 构建 出 的 路 径 表 达 式 ， 如 果 没 
有 匹配 上 的 服务 则 还 是 会 使 用 默认 的 路 由 映射 规则 ， 即 采用 完整 服务 名 
作为 前 级 的 路 径 表 达 式 。 


路 径 风 配 


不 论 是 使 用 传统 路 由 的 配置 方式 还 是 服务 路 由 的 配置 方式 ， 我 们 都 
再 要 为 每 个 路 由 规则 定义 匹配 表达 式 ， 也 就 是 上 面 所 说 的 path 参 数 。 在 
Zuul 中 ， 路 由 匹配 的 路 径 表 达 式 采用 了 Ant 风 格 定义 。 
Ant 风 格 的 路 径 表 达 式 使 用 起 来 非 第 简单 ， 它 一 共有 下 面 这 三 种 通 配 














大全 


符 


我 们 可 以 通过 下 表 中 的 示例 来 进一步 理解 这 三 个 通配符 的 含义 并 进 
行 参 考 使 用 。 


另外 ， 当 我 们 使 用 通配符 的 时 候 ， 经 常会 伴 到 这 样 的 问题 : 一 个 
URL 路 径 可 能 会 被 多 个 不 同 路 由 的 表达 式 匹 配 上 。 比 如 ， 有 这 样 一 个 场 
景 ， 我 们 在 系统 建设 的 一 开始 实现 了 user-service 服 务 ， 并 用 配置 了 如 下 
路 由 规则 : 

zuul.routes.user-service.path=/user-service/** 

zuul.routes.user-service.serviceld=user-service 

但 是 随 着 版 本 的 迭代 ， 我 们 对 user-service 服务 做 了 一 些 功 能 拆 分 ， 
将 原 属 于 user-service 服务 的 某 些 功能 拆 分 到 了 另外 一 个 全 新 的 服务 
user-service-ext 中 去 ， 而 这 些 拆 分 的 外 部 调用 URL 路 径 希 望 能 够 符合 规 
则 /user-service/ext/**， 这 个 时 候 我 们 需要 就 在 配置 文件 中 增加 一 个 路 由 
规则， 完整 配置 如 下 : 

zuul.routes.user-service.path=/user-service/** 

zuul.routes.user-service.serviceld=user-service 

zuul.routes.user-service-ext.path=/user-service/ext/** 
zuul.routes.user-service-ext.serviceld=user-service-ext 





此 时 ， 调 用 user-service-ext ”服务 的 ”URL 路 径 实 际 上 会 同时 
被 /aserservice/#x#+ 和 /user-service/ext/*## 两 个 表达 式 所 匹配 。 在 逻辑 上 ， 

API “网 关 服 务 需 要 优先 选择 /user-service/ext/#* 路 由 ， 然 后 再 匹配 /user- 
service/** 路 由 才能 实现 上 述 需 求 。 但 是 如 果 使 用 上 面 的 配置 方式 ， 实 际 
上 是 无 法 保证 这 样 的 路 由 优先 顺序 的 。 

从 下 面 的 路 由 匹配 算法 中 ， 我 们 可 以 看 到 它 在 使 用 路 由 规则 匹配 请 
求 路 径 的 时 候 是 通过 线性 过 历 的 方式 ， 在 请 求 路 径 获 取 到 第 一 个 匹配 的 
路 由 规则 之 后 束 返 回 并 结束 匹配 过 程 。 所 以 当 存 在 多 个 匹配 的 路 由 规则 
时 ， 匹 配 结果 完全 取决 于 路 由 规则 的 保存 顺序 。 

Override 

public Route getMatchingRoute (final String path) { 








ZuulRoute route=null; 

if (! matchesIgnoredPatterns (adjustedPath) ) { 

for (Entry<String,ZuulRoute> entry 
this.routes.get () .entrySet () ) { 

String pattern=entry.getKey (); 

log.debug ("Matching pattern:"+pattern ) ; 

if (this.pathMatcher.match (pattern,adjustedPath) ) { 

route=entry.getValue (); 

break:;: 

} 

} 

} 

log.debug ("route matched="+route) ; 

return getRoute (route,adjustedPath) ; 


} 

下 面 所 示 的 代码 是 基础 的 路 由 规则 加 载 算法 ， 我 们 可 以 看 到 这 些 路 
由 规则 是 通过 LinkedHashMap 保 存 的 ， 也 就 是 说 ， 路 由 规则 的 保存 是 有 
序 的 ， 而 内 容 的 加 载 是 通过 过 历 配置 文件 中 路 由 规则 依次 加 入 的 ， 所 以 
导致 问题 的 根本 原因 是 对 配置 文件 中 内 容 的 读 取 。 

protected Map<String,ZuulRoute> locateRoutes () { 

LinkedHashMap<String,ZuulRoute> routesMap=new 
LinkedHash Map<String,ZuulRoute> 〈) ; 

for (ZuulRoute route : this.properties.getRoutes () .values () ) { 

routesMap.put (route.getPath () ,route) ; 

} 











return routesMap; 


由 于 properties 的 配置 内 容 无 法 保证 有 序 ， 所 以 当 出 现 这 种 情况 的 时 
候 ， 为 了 保证 路 由 的 优先 顺序 ， 我 们 需要 使 用 YAML 文 件 来 配置 ， 以 实 
现 有 序 的 路 由 规则 ， 比 如 使 用 下 面 的 定义 : 

zuul: 

routes: 

usSer-service-ext: 

path: /user-service/ext/** 

serviceld: user-service-ext 

User-service: 

path: /user-service/** 

serviceld: user-service 

通过 path 参 数 定义 的 Ant 表 达 式 已 经 能 够 完成 API 网 关上 的 路 由 规则 
配置 功能 ， 但 是 为 了 更 细 粒 度 和 更 为 灵活 地 配置 路 由 规则 ，Zuul 还 提供 
了 一 个 忽略 表达 式 参 数 zuul.ignored-patterns。 该 参数 可 以 用 来 设置 不 希 
望 被 API 网 关 进 行路 由 的 URL 表 达 式 。 

比如 ， 以 快速 入 门 中 的 示例 为 基础 ， 如 采 不 希望 /hello 接口 被 路 由 ， 
那么 我 们 可 以 这 样 设置 : 

zuul.ignored-patterns=/**/hello/** 

zuul.routes.api-a.path=/api-a/** 

zuul.routes.api-a.serviceld=hello-service 

然后 ， 可 以 尝试 通过 网 关 来 访问 hello-service ”的 /hello 接口 
http://localhost:5555/api-a/hello。 昌 然 该 访问 路 径 完 全 符合 path 参数 定义 
的 /api-a/** 规 则 ， 但 是 由 于 该 路 径 符合 zuul.ignored-patterns 参 数 定义 的 规 
则 ， 所 以 不 会 被 正确 路 由 。 同 时 ， 我 们 在 控制 台 或 日 志 中 还 能 看 到 没有 
匹配 路 由 的 输出 信息 : 

0.S.C.n.Z.{f.pre.PreDecorationFilter : No route found for uri: /api-a/hello 

另外 ， 该 参数 在 使 用 时 还 需要 注意 它 的 范围 并 不 是 对 某 个 路 由 ， 而 
是 对 所 有 路 由 。 上 所 以 在 设置 的 时 候 需 要 全 面 考 虑 URL 规 则 ， 防 止 忽略 了 
不 该 被 忽略 的 URL 路 径 。 


路 由 前 j 级 


为 了 方便 全 局 地 为 路 由 规则 增加 前 级 信息 ，Zuul 提 供 了 zuul.prefix 参 
数 来 进行 设置 。 比 如 ， 硕 望 为 网 天 上 的 路 由 规则 都 增加 /api 前 级 ， 那 么 





我 们 可 以 在 配置 文件 中 增加 配置 : zuul.prefix=/api。 另 外 ， 对 于 代理 前 
缀 会 默认 从 路 径 中 移 除 ， 我 们 可 以 通过 设置 zuul.stripPrefix=false 来 关闭 
该 移 除 代理 前 绥 的 动作 ， 也 可 以 通过 zuul.routes.<route>.strip-prefix=true 
来 对 指定 路 由 关闭 移 除 代理 前 绥 的 动作 。 

注意 ， 在 使 用 zuul.prefix 参 数 的 时 候 ， 目 前 版 本 的 实现 还 存在 一 些 
Bug， 所 以 请 齐 慎 使 用 ,或 是 避 开 会 引发 Bug 的 配置 规则 。 具 体会 引发 
Bug 的 规则 如 下 : 

假设 我 们 设置 zuul.prefix=/api， 当 路 由 规则 的 path 表 达 式 以 /api 开 头 的 
时 候 ， 将 会 产生 错误 的 映射 关系 。 可 以 进行 下 面 的 配置 实验 来 验证 这 个 
问题 : 

zuul.routes.api-a.path=/api/a/** 

zuul.routes.api-a.serviceld=hello-service 

zuul.routes.api-b.path=/api-b/** 

zuul.routes.api-b.serviceld=hello-service 

zuul.routes.api-c.path=/ccc/** 

zuul.routes.api-c.serviceld=hello-service 

这 里 配置 了 三 个 路 由 关系 : /api/a**、/api-b/**、/ccc/**， 这 三 个 路 
径 规则 都 将 被 路 由 到 hello-service 服 务 上 去 。 当 我 们 没有 设置 
Zuul.prefix=/api 的 时 候 ， 一 切 运作 正常 。 但 是 在 增加 了 zuul.prefix=/api 配 
置 之 后 ， 会 得 到 下 面 这 样 的 路 由 关系 : 








0.s.c.n.zuul.web.ZuulHandlerMapping : Mapped URL 
path[/api/api/a/a/**]onto 

handler of typelclass 
org.springframework.cloud.netflix.zuul.web.ZuulController] 

0.s.c.n.zuul.web.ZuulHandlerMapping : Mapped URL path[L/api/api- 
b-b/**]onto 

handler of typelclass 
org.springframework.cloud.netflix.zuul.web.ZuulController] 

0.s.c.n.zuul.web.ZuulHandlerMapping | Mapped URL 
path[/api/ccc/**]onto 

handler of typelclass 


org.springframework.cloud.netflix.zuul.web.ZuulController] 

从 日 志 信 息 中 我 们 可 以 看 到 ， 以 /api 开 头 的 路 由 规则 解析 除了 两 个 看 
似 就 有 问题 的 映射 URL， 我 们 可 以 通过 该 输出 的 URL 来 访问 ， 实 际 是 
路 人 的 服务 接口 的 ， 只 有 非 /api 开 头 的 路 由 规则 /ccc/#* 能 够 正 
常 路 由 。 

上 述 实验 基于 Brixton.SR7 和 Camden.SR3 测 试 均 存 在 问题 ， 所 以 在 使 


用 该 版 本 或 以 下 版 本 时 候 ， 务 必 避 免 让 路 由 表达 式 的 起 始 字 符 串 与 
zuul.prefix 参 数 相同 。 


本 地 跳 转 


在 Zuul 实 现 的 API 网 关 路 由 功能 中 ， 还 支持 forward 形 式 的 服务 端 跳 转 
配置 。 实 现 方式 非常 简单 ， 只 需 通 过 使 用 path 与 rl 的 配置 方式 束 能 完 
成 ， 通 过 ur 中 使 用 forward 来 指定 需要 跳 转 的 服务 器 资源 路 径 。 

下 面 的 配置 实现 了 两 个 路 由 规则 ，api-a 路 由 实现 了 将 符合 /api-a/** 规 
则 的 请 求 转发 到 http://localhost:8001/; 而 api-b 路 由 则 使 用 了 本 地 跳 转 ， 

它 实 现 了 将 符合 /api-b/** 规 则 的 请 求 转发 到 API 网 天 中 以 /local 为 前 级 的 
请 求 上 ， 由 API 网 关 进 行 本 地 处 理 。 比 如 ， 当 API 网 关 接 收 到 请 求 /api- 
b/hello， 它 符合 api-b 的 路 由 规则 ， 所 以 该 请 求 会 被 API 网 关 转 发 到 网 关 
的 /local/hello 请 求 上 进行 本 地 处 理 。 

zuul.routes.api-a.path=/api-a/** 

zuul.routes.api-a.url=http://localhost:8001/ 

zuul.routes.api-b.path=/api-b/** 

zuul.routes.api-b.url=forward:/local 

这 里 要 注意 ， 由 于 需要 在 API 网 关上 实现 本 地 跳 转 ， 所 以 相应 的 我 们 
也 需要 为 本 地 跳 转 实现 对 应 的 请 求 接口 。 按 照 上 面 的 例子 ， 在 API 网 关 
上 还 需要 增加 一 个 /local/hello 的 接口 实现 才能 让 api-b 路 由 规则 生效 ， 比 
如 下 面 的 实现 。 否 则 Zuul 在 进行 forward 转 发 的 时 候 会 因为 找 不 到 该 请 求 
而 返回 404 错 误 。 

(DRestController 

public class HelloController { 

@RequestMapping ("/local/hello") 

public String hello () { 

return "Hello World Local"; 








默认 情况 下 ，Spring Cloud Zuul 在 请 求 路 由 时 ， 会 过 滤 掉 HTTP 请 求 
头 信息 中 的 一 些 敏感 信息 ， 防 止 它们 被 传递 到 下 游 的 外 部 服务 器 。 默 认 
的 敏感 头 信息 通过 zuul.sensitiveHeaders 参 数 定 义 ， 包 括 Cookie、Set- 
Cookie、Authorization 三 个 属性 。 所 以 ， 我 们 在 开发 Web 项 目 时 常用 的 


Cookie 在 Spring Cloud Zuul 网 关中 默认 是 不 会 传递 的 ， 这 束 会 引发 一 个 
常见 的 问题 ， 如 果 我 们 要 将 使 用 了 Spring Security、Shiro 等 安全 框架 构 
建 的 Web 应 用 通过 Spring ”Cloud ”Zuul 构 建 的 网 关 来 进行 路 由 时 ， 由 于 
Cookie 信 息 无 法 传递 ， 我 们 的 Web 应 用 将 无 法 实现 登录 和 鉴 权 。 为 了 解 
决 这 个 问题 ， 配 置 的 方法 有 很 多 。 

e 通 过 设置 全 局 参数 为 空 来 窗 新 默认 值 ， 具 体 如 下 : 

zuul.sensitiveHeaders= 

这 种 方法 并 不 推荐 ， 虽 然 可 以 实现 Cookie 的 传递 ， 但 是 破坏 了 默认 
设置 的 用 意 。 在 微服 务 架构 的 API 网 关 之 内 ， 对 于 无 状态 的 RESTful API 
请 求 肯 定 是 要 远 多 于 这 些 Web 类 应 用 请 求 的 ， 甚 至 还 有 一 些 染 构 设 计 会 
将 Web 类 应 用 和 App 客 户 端 一 样 都 归 为 API 网 关 之 外 的 客户 端 应 用 。 

e 通 过 指定 路 由 的 参数 来 配置 ， 方 法 有 下 面 两 种 。 

# 方法 一 : 对 指定 路 由 开局 目 定 义 敏感 头 

zuul.routes.<router>.customSensitiveHeaders=true 

# 方法 二 : 将 指定 路 由 的 敏感 头 设置 为 衬 

zuul.routes.<router>.sensitiveHeaders= 

比较 推荐 使 用 这 两 种 方法 ， 仅 对 指定 的 web 应 用 开局 对 敏感 信息 的 
传递 ， 影 响 范 围 小 ， 不 至 于 引起 其 他 服务 的 信息 泄露 问题 。 

重 定 癌 问题 

在 解决 了 Cookie 问题 之 后 ， 我 们 已 经 能 够 通过 网 关 来 访问 并 登录 到 
我 们 的 Web 应 用 了 。 但 是 这 个 时 候 又 会 发 现 另外 一 个 问题 虽然 可 以 
通过 网 关 访 问 登 录 页 面 并 发 起 登录 请 求 ， 但 是 登录 成 功 之 后 ， 我 们 跳 转 
到 的 页 面 URL 却 是 具体 Web 应 用 实例 的 地 址 ， 而 不 是 通过 网 关 的 路 由 地 
址 。 这 个 问题 非常 严重 ， 因 为 使 用 API 网 关 的 一 个 重要 原因 就 是 要 将 网 
关 作 为 统一 入 口 ， 从 而 不 暴露 所 有 的 内 部 服务 细节 。 那 么 是 什么 原因 导 
致 了 这 个 问题 呢 ? 

通过 浏览 右 开 发 工具 查看 登录 以 及 登录 之 后 的 请 求 详情 ， 可 以 发 
现 ， 引 起 问题 的 大 致 原因 是 由 于 Spring ”Security 或 Shiro 在 登录 完成 之 
后 ， 通 过 重 定 问 的 方式 跳 转 到 登录 后 的 页 面 ， 此 时 登录 后 的 请 求 结果 状 
态 码 为 302， 请 求 响应 头 信息 中 的 ” Location 指向 了 具体 的 服务 实例 地 
址 ， 而 请 求 头 信息 中 的 Host 也 指向 了 有 具体 的 服务 实例 耻 地 址 和 端口 。 所 
以 ， 该 问题 的 根本 原因 在 于 Spring Cloud Zuul 在 路 由 请 求 时 ， 并 没有 将 
最 初 的 Host 信 息 设 置 正 确 。 那 么 如 何 解 决 这 个 问题 呢 ? 

针对 这 个 问题 ， 目 前 在 spring-cloud-netflix-core-1.2.x 版 本 的 Zuul 中 增 
加 了 一 个 参数 配置 ， 能 够 使 得 网 关 在 进行 路 由 转发 前 为 请 求 设 置 Host 头 
信息 ， 以 标识 最 初 的 服务 端 请 求 地 址 。 且 体 配置 方式 如 下 : 


Zuul.addHostHeader=true 


















































由 于 Spring Cloud 的 版 本 依赖 原因 ， 目 前 的 Brixton 版 本 采用 了 
spring-cloud-netflix-core-1.1.x， 只 有 Camden 版 本 采用 了 spring-cloud- 
netflix-core-1.2.x。 所 以 重 定 同 的 问题 如 果 要 在 Zuul 中 解决 ， 最 简单 的 方 
法 束 使 用 Camden 版 本 。 如 果 要 在 Brixton 版 本 中 解决 ， 可 以 参考 Camden 
的 PreDecorationFilter 的 实现 扩展 过 滤器 链 来 增加 Host 信 息 。 


Hystrix 和 Ribbon 文 持 


在 “快速 入 门 ” 一 节 中 介绍 spring-cloud-starter-zuul 依赖 时 ， 我 们 提 到 
了 它 自 身 就 包含 了 对 spring-cloud-starter-hystrix “和 spring-cloud- 
starterribbon 模 块 的 依赖 ， 所 以 Zuul 天 生 就 拥有 线程 隔离 和 断路 需 的 自我 
保护 功能 ， 以 及 对 服务 调用 的 客户 站 负载 均衡 功能 。 但 是 需要 注意 ， 当 
使 用 path 与 url 的 映射 关系 来 配置 路 由 规则 的 时 候 ， 对 于 路 由 转发 的 请 求 
不 会 采用 HystrixCommand 来 包装 ， 所 以 这 类 路 由 请 求 没有 线程 隔离 和 
时 路 器 的 保护 ， 并 且 也 不 会 有 负载 均衡 的 能 力 。 因 此 ， 我 们 在 使 用 Zuul 
的 时 候 尽 量 使 用 path 和 serviceId 的 组 合 来 进行 配置 ， 这 样 不 仅 可 以 保证 
API 网 关 的 健壮 和 稳定 ， 也 能 用 到 Ribbon 的 客户 病 负 载 均衡 功能 。 

我 们 在 使 用 Zuul 搭 建 API 网 关 的 时 候 ， 可 以 通过 Hystrix 和 Ribbon 的 参 
数 来 调整 路 由 请 求 的 各 种 超时 时 间 等 配置 ， 比 如 下 面 这 些 参 数 的 设置 。 

ehystrix.command.default.execution.isolation.thread.timeoutIn 
Milliseconds: 该 参数 可 以 用 来 设置 API 网 关中 路 由 转发 请 求 的 
HystrixCommand ”执行 超时 时 间 ， 单 位 为 又 秒 。 当 路 由 转发 请 求 的 命令 
执行 时 间 超 过 该 配置 值 之 后 ，Hystrix 会 将 该 执行 命令 标记 为 TIMEOUT 
并 抛 出 异常 ，Zuul 会 对 该 异常 进行 处 理 并 返回 如 下 JSON 信 息 给 外 部 调 
用 方 。 

{ 

"timestamp": 1481350975323, 

"status": 500, 

"error": "Internal Server Error", 

"exception": "com.netflix.zuul.exception.ZuulException", 

"message": "TIMEOUT" 

} 

eribbon.ConnectTimeout: 该 参数 用 来 设置 路 由 转发 请 求 的 时 候 ， 创 
建 请 求 连接 的 超时 时 间 。 当 ribbon.ConnectTimeout 的 配置 值 小 于 
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds 配 
置 值 的 时 候 ， 大 出现 路 由 请 求 出 现 连接 超时 ， 会 自动 进行 重 试 路 由 请 
求 ， 如 采 重 试 依 然 失 败 ，Zuul 会 返回 如 下 JSON 信 息 给 外 部 调用 方 。 








{ 

"timestamp": 1481352582852, 
"status": 500, 

"error": "Internal Server Error", 


"exception": "com.netflix.zuul.exception.ZuulException", 
"message": "NUMBEROF_RETRIES NEXTSERVER _ EXCEEDED" 


} 

如 果 ribbon.ConnectTimeout 的 配置 值 大 于 
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds 配 
置 值 的 时 候 ， 当 出 现 路 由 请 求 连 接 超 时 时 ， 由 于 此 时 对 于 路 由 转发 的 请 
求 命令 已 经 超时 ， 上 所 以 不 会 进行 重 试 路 由 请 求 ， 而 是 直接 按 请 求 命令 超 
时 处 理 ， 返 回 TIMEOUT 的 错误 信息 。 

eribbon.ReadTimeout: 该 参数 用 来 设置 路 由 转发 请 求 的 超时 时 间 。 
它 的 处 理 与 ribbon.ConnectTimeout 类 似 ， 只 是 它 的 超时 是 对 请 求 连 接 建 
立 之 后 的 处 理 时 间 。 当 ribbon.ReadTimeout 的 配置 值 小 于 
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds 配 
置 值 的 时 候 ， 大 路 由 请 求 的 处 理 时 间 超 过 访 配 置 值 且 依 赖 服务 的 请 求 还 
未 啊 应 的 时 候 ， 会 目 动 进行 重 试 路 由 请 求 。 如 有 果 重 试 后 依然 没有 获得 请 
求 响应 ，Zuu 会 返回 
NUMBEROF RETRIES_NEXTSERVER_EXCEEDED 错 误 。 如 果 
ribbon.ReadTimeout 的 配置 值 大 于 
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds 配 
置 值 ， 若 路 由 请 求 的 处 理 时 间 超 过 该 配置 值 且 依赖 服务 的 请 求 还 未 响应 
时 ， 不 会 进行 重 试 路 由 请 求 ， 而 是 直接 按 请 求 命令 超时 处 理 ， 返 回 
TIMEOUT 的 错误 信息 。 

根据 上 面 的 介绍 我 们 可 以 知道 ， 在 使 用 Zuul 的 服务 路 由 时 ， 如 果 路 
由 转发 请 求 发 生 超时 《连接 超时 或 处 理 超时 ) ， 只 要 超时 时 间 的 设置 小 
于 Hystrix 的 命令 超时 时 间 ， 那 么 它 就 会 目 动 发 起 重 试 。 但 是 在 有 些 情况 
下 ， 我 们 可 能 需要 关闭 该 重 试 机 制 ， 那 么 可 以 通过 下 面 的 两 个 参数 来 进 
行 设置 : 

zuul.retryable=false 

zuul.routes.<route>.retryable=false 

其 中 ，zuul.retryable 用 来 全 局 关闭 重 试 机 制 ， 而 zuul.routes. 
<route>.retryable=false 则 是 指定 路 由 关闭 重 试 机 制 。 
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滤器 详解 
J 


在 本 章 一 开始 的 快速 入 门 示例 中 ， 我 们 已 经 介绍 了 一 部 分 关于 请 求 
过 滤 的 功能 。 在 本 节 中 ， 我 们 将 对 Zuul 的 请 求 过 滤器 功能 做 进一步 的 介 


绍 和 总 结 。 
过 滤器 


通过 快速 入 门 的 示例 ， 我 们 对 于 Zuu 的 第 一 印象 通常 是 这 样 的 : 它 
包含 了 对 请 求 的 路 由 和 过 滤 两 个 功能 ， 其 中 路 由 功能 负责 将 外 部 请 求 转 
发 到 具体 的 微服 务实 例 上 ， 是 实现 外 部 访问 统一 入 口 的 基础 ， 而 过 滤 右 
功能 则 负责 对 请 求 的 处 理 过 程 进行 干预 ， 是 实现 请 求 校 验 、 服 务 聚 合 等 
功能 的 基础 。 然 而 实际 上 ， 路 由 功能 在 真正 运行 时 ， 它 的 路 由 映射 和 请 
求 转发 都 是 由 几 个 不 同 的 过 小 器 完成 的 。 其 中 ， 路 由 映射 主要 通过 pre 
类 型 的 过 小 器 完成 ， 它 将 请 求 路 径 与 配置 的 路 由 规则 进行 匹配 ， 以 找到 
需要 转发 的 目标 地 址 ; 而 请 求 转发 的 部 分 则 是 由 route 类 型 的 过 滤器 来 完 
成 ， 对 pre 类 型 过 滤器 获得 的 路 由 地 址 进行 转发 。 所 以 ， 过 滤器 可 以 说 
是 Zuul 实 现 API 网 关 功 能 最 为 核心 的 部 件 ， 每 一 个 进入 Zuul 的 HTTP 请 求 
都 会 经 过 一 系列 的 过 滤器 处 理 链 得 到 请 求 啊 应 并 返回 给 客户 并 。 

在 Spring Cloud Zuul 中 实现 的 过 滤器 必须 包含 4 个 基本 特征 :过滤 类 
型 、 执 行 顺 序 、 执 行 条 件 、 具 体操 作 。 这 些 元 素 看 起 来 非常 熟悉 ， 实 际 
上 它 就 是 ZuulFilter 接 口中 定义 的 4 个 抽象 方法 : 

String filterType 〈) ; 

int filterOrder () ; 

boolean shouldFilter () ; 

Object run (); 

它们 各 自 的 含义 与 功能 总 结 如 下 。 

efilterType: 该 函数 需要 返回 一 个 字符 串 来 代表 过 滤器 的 类 型 ， 而 这 
个 类 型 就 是 在 HTTP 请 求 过 程 中 定义 的 各 个 阶段 。 在 Zuul 中 默认 定义 了 4 
种 不 同 生 命 周 期 的 过 滤器 类 型 ， 具 体 如 下 所 示 。 

pre: 可 以 在 请 求 被 路 由 之 前 调用 。 

@rOouting: 在 路 由 请 求 时 被 调用 。 

加 post: 在 routing 和 error 过 滤器 之 后 被 调用 。 

加 error: 处 理 请 求 时 发 生 错 误 时 被 调用 。 

efilterOrder: 通过 int 值 来 定义 过 滤 堪 的 执行 顺序 ， 数 值 越 小 优先 级 

















越 高 。 

eshouldFilter: 返回 一 个 boolean 值 来 判断 该 过 滤器 是 否 要 执行 。 我 们 
可 以 通过 此 方法 来 指定 过 滤器 的 有 效 范 围 。 

erun: 过 滤器 的 具体 逻辑 。 在 该 函数 中 ， 我 们 可 以 实现 自 定义 的 过 
滤 逻 辑 ， 来 确定 是 否 要 拦截 当前 的 请 求 ， 不 对 其 进行 后 续 的 路 由 ， 或 是 
在 请 求 路 由 返回 结果 之 后 ， 对 处 理 结果 做 一 些 加 工 等 。 


请 求生 命 周 期 


对 于 Zuul 中 的 过 滤器 类 型 filterType， 我 们 已 经 做 过 一 些 简单 的 介 
绍 。Zuul 默 认定 义 了 4 种 不 同 的 过 滤器 类 型 ， 它 们 窗 盖 了 一 个 外 部 HTTP 
请 求 到 达 API 网 关 ， 直 到 返回 请 求 结 果 的 全 部 生命 周期 。 下 图 源 自 Zuul 
的 官方 WiKi 中 关于 请 求生 命 周 期 的 图 解 ， 它 描述 了 一 个 HTTP 请 求 到 达 
API 网 天 之 后 ， 如 何在 各 种 不 同类 型 的 过 小 器 之 间 流 转 的 详细 过 程 。 


从 上 图 中 我 们 可 以 看 到 ， 当 外 部 HTTP 请 求 到 达 API 网 关 服 务 的 时 
候 ， 首 先 它 会 进入 第 一 个 阶段 pre， 在 这 里 它 会 被 pre 类 型 的 过 滤器 进行 
处 理 ， 该 类 型 过 滤器 的 主要 目的 是 在 进行 请 求 路 由 之 前 做 一 些 前 置 加 
工 ， 比 如 请 求 的 校 验 等 。 在 完成 了 pre 类 型 的 过 滤器 处 理 之 后 ， 请 求 进 
入 第 二 个 阶段 routing， 也 就 是 之 前 说 的 路 由 请 求 转 发 阶段 ， 请 求 将 会 被 
routing 类 型 过 滤器 处 理 。 这 里 的 具体 处 理 内 容 就 是 将 外 部 请 求 转发 到 具 
体 服务 实例 上 去 的 过 程 ， 当 服务 实例 将 请 求 结 果 都 返回 之 后 ，routing 阶 
段 完 成 ， 请 求 进 入 第 三 个 阶段 post。 此 时 请 求 将 会 被 post 类 型 的 过 滤器 
处 理 ， 这 些 过 滤器 在 处 理 的 时 候 不 仅 可 以 获取 到 请 求 信 息 ， 还 能 获取 到 
服务 实例 的 返回 信息 ， 所 以 在 post 类 型 的 过 滤器 中 ， 我 们 可 以 对 处 理 结 
果 进 行 一 些 加 工 或 转换 等 内 容 。 另 外 ， 还 有 一 个 特殊 的 阶段 error， 该 阶 
段 只 有 在 上 述 三 个 阶段 中 发 生 异 常 的 时 候 才 会 触发 ,但 是 它 的 最 后 流 问 
还 是 post 类 型 的 过 滤器 ， 因 为 它 需 要 通过 post 过 滤器 将 最 终结 果 返 回 给 
请 求 客户 端 ( 对 于 error 过 滤器 的 处 理 ， 在 Spring Cloud Zuul 的 过 滤 链 中 
实际 上 有 一 些 不 同 ， 后 续 我 们 在 介绍 核心 过 滤器 时 会 做 详细 分 析 〉。 














在 Spring Cloud Zuu 中 ， 为 了 让 API 网 关 组 件 可 以 被 更 方便 地 使 用 ， 
它 在 HTTP 请求 生命 周期 的 各 个 阶段 默认 实现 了 一 批 核心 过 滤器 ， 它 们 
会 在 API 网 关 服 务 启动 的 时 候 被 自动 加 载 和 局 用 。 我 们 可 以 在 源码 中 碍 
看 和 了 解 它 们 ， 它 们 定义 于 spring-cloud netflix-core 模块 的 


org.springframework.cloud.netflix.zuul.filters 包 下 。 

如 下 图 所 示 ， 在 默认 局 用 的 过 滤 费 中 包含 三 种 不 同 生命 周 期 的 过 滤 
人 妖 ， 这 些 过 滤器 都 非 第 重要 ， 可 以 帮助 我 们 理解 Zuul 对 外 部 请 求 处 理 的 
过 程 ， 以 及 帮助 我 们 在 此 基础 上 扩展 过 滤器 去 完成 自身 系统 需要 的 功 
能 。 下 面 ， 我 们 将 逐个 对 这 些 过 滤器 做 详细 的 介绍 。 


pre 过 小 器 

eServletDetectionFilter: 它 的 执行 顺序 为 -3， 是 最 先 被 执行 的 过 滤 
器 。 访 过 滤器 总 是 会 被 执行 ， 主 要 用 来 检测 当前 请 求 是 通过 Spring 的 
DispatcherServlet 处 理 运行 的 ， 还 是 通过 ZuulServlet 来 处 理 运行 的 。 它 的 
检测 结果 会 以 布尔 类 型 保存 在 当前 请 求 上 下 文 的 
isDispatcherServletRequest 参 数 中 ， 这 样 在 后 续 的 过 滤器 中 ， 我 们 就 可 以 
通过 RequestUtils.isDispatcherServletRequest () 和 
RequestUtils.isZuulServletRequest〈) 方法 来 判断 请 求 处 理 的 源头 ， 以 实 
现 后 续 不 同 的 处 理 机 制 。 一 般 情 况 下 ， 发 送 到 API 网 关 的 外 部 请 求 都 会 
被 Spring 的 DispatcherServlet 处 理 ， 除 了 通过 /zuul/#* 路 径 访 问 的 请 求 会 
绕 过 DispatcherServlet， 被 ZuulServlet 处 理 ， 主 要 用 来 应 对 处 理 大 文件 上 
传 的 情况 。 另 外 ， 对 于 ”ZuulServlet 的 访问 路 径 /zuul*， 我 们 可 以 通过 
Zuul.servletPath 参 数 来 进行 修改 。 

eServlet30WrapperFilter: 它 的 执行 顺序 为 -2， 是 第 二 个 执行 的 过 渡 
器 。 目 前 的 实现 会 对 所 有 请 求生 效 ， 主 要 为 了 将 原始 的 
httpServletRequest 包装 成 Servlet30RequestWrapper 对 象 。 

eFormBodyWrapperFilter: 它 的 执行 顺序 为 -1， 是 第 三 个 执行 的 过 滤 
器 。 访 过 滤器 仅 对 两 类 请 求生 效 ， 第 一 类 是 Content-Type 为 
application/x-wwwform-urlencoded 的 请 求 ， 第 二 类 是 Content-Type 为 
multipart/formdata 并 且 是 由 Spring 的 DispatcherServlet 处 理 的 请 求 〈 用 
到 了 ServletDetectionFilter 的 处 理 结果 ) 。 而 该 过 小 器 的 主要 目的 是 将 符 
合 要 求 的 请 求 体 包装 成 FormBodyRequestWrapper 对 象 。 

eDebugFilter: 它 的 执行 顺序 为 1， 是 第 四 个 执行 的 过 小 器。 该 过 渡 
妖 会 根据 配置 参数 zuul.debug.request 和 请 求 中 的 debug 参 数 来 决定 是 否 执 
行 过 滤器 中 的 操作 。 而 它 的 具体 操作 内 容 则 是 将 当前 请 求 上 下 文中 的 
debugRouting 和 debugRequest 参 数 设 置 为 hue。 由 于 在 同一 个 请 求 的 不 同 
生命 周期 中 都 可 以 访问 到 这 两 个 值 ， 所 以 我 们 在 后 续 的 各 个 过 滤器 中 可 
以 利用 这 两 个 值 来 定义 一 些 debug 信息 ， 这 样 当 线 上 环境 出 现 问 题 的 时 
候 ， 可 以 通过 请 求 参数 的 方式 来 激活 这 些 debug 信 息 以 帮助 分 析 问 题 。 
另外 ， 对 于 请 求 参 数 中 的 debug 参 数 ， 我 们 也 可 以 通过 
Zuul.debug.parameter 来 进行 目 定义 。 














ePreDecorationFilter: 它 的 执行 顺序 为 5， 是 pre 阶 段 最 后 被 执行 的 过 
滤 右 。 该 过 滤 右 会 判断 当前 请 求 上 下 文中 是 否 存 在 forward.to 和 和 serviceld 
参数 ， 如 果 都 不 存在 ， 那 么 它 就 会 执行 具体 过 滤 右 的 操作 (如 果 有 一 个 
存在 的 话 ， 说 明 当 前 请 求 已 经 被 处 理 过 了 ， 因 为 这 两 个 信息 就 是 根据 当 
前 请 求 的 路 由 信息 加 载 进 来 的 ) 。 而 它 的 具体 操作 内 容 束 是 为 当前 请 求 
似 “ 旦 斋 久 理 ， 比如 ， 进 行路 由 规则 的 匹配 、 在 请 求 上 下 文中 设置 该 请 
求 的 基本 信息 以 及 将 路 由 匹配 结果 等 一 些 设置 信息 等 ， 这 些 信息 将 是 后 
续 过 滤器 进行 处 理 的 重要 依据 ， 我 们 可 以 通过 
RequestContext.getCurrentContext 〈) 来 访问 这 些 信息 。 男 外 ， 我 们 还 可 
以 在 该 实现 中 找到 一 些 对 http 头 请 求 进行 处 理 的 逻辑 ， 其 中 包含 了 一 些 
耳熟能详 的 头 域 ， 比 如 X-Forwarded-Host、X-Forwarded-Port。 另 外 ， 对 
于 这 些 头 域 的 记录 是 通过 zuul.addProxyHeaders ”参数 进行 控制 的 ， 而 这 
个 参数 的 默认 值 为 tue， 所 以 Zuu 在 请 求 跳 转 时 默认 会 为 请 求 增 加 X- 
Forwarded-* 头 域 ， 包 括 X-ForwardedHost、X-Forwarded-Port、X- 
Forwarded-For、X-Forwarded-Prefix、X-Forwarded-Proto。 也 可 以 通过 设 
置 zuul.addProxyHeaders=false 关 闭 对 这 些 头 域 的 添加 动作 。 

route 过 滤器 

eRibbonRoutingFilter: 它 的 执行 顺序 为 10， 是 route 阶 段 第 一 个 执行 
的 过 滤器 。 访 过 滤器 只 对 请 求 上 下 文中 存在 serviceId 参 数 的 请 求 进行 处 
理 ， 即 只 对 通过 serviceId 配 置 路 由 规则 的 请 求生 效 。 而 该 过 滤器 的 执行 
逻辑 就 是 面 问 服务 路 由 的 核心 ， | Ribbon 和 Hystrix 来 向 服务 实 
例 发 起 请 求 ， 并 将 服务 实例 的 请 求 结 果 返 

eSimpleHostRoutingFilter: 它 的 执行 pe 为 100， 是 route 阶 段 第 二 个 
执行 的 过 滤器 。 该 过 滤器 只 对 请 求 上 下 文中 存在 routeHost 参 数 的 请 求 进 
行 处 理 ， 即 只 对 通过 url 配置 路 由 规则 的 请 求生 效 。 而 该 过 滤器 的 执行 
罗 辑 就 是 直接 回 routeHost 参数 的 物理 地 址 发 起 请 求 ， 从 源码 中 我 们 可 以 
知道 该 请 求 是 直接 通过 httpclient 包 实现 的 ， 而 没有 使 用 Hystrix 命 令 进行 
包装 ， 所 以 这 类 请 求 并 没有 线程 隔离 和 断路 器 的 保护 。 

eSendForwardFilter: 它 的 执行 顺序 为 500， 是 route 阶 段 第 三 个 执行 
的 过 滤器 。 该 过 滤 堪 只 对 请 求 上 下 文中 存在 forward.to 参 数 的 请 求 进行 处 
理 ， 即 用 来 处 理 路 由 规则 中 的 forward 本 地 跳 转 配置 。 

post 过 小 器 

eSendErrorFilter: 它 的 执行 顺序 为 0， 是 post 阶段 第 一 个 执行 的 过 滤 
器 。 该 过 滤器 仅 在 请 求 上 下 文中 包含 error.status_code 参数 (由 之 前 执 
行 的 过 滤器 设置 的 错误 编码 ) 并 且 还 没有 被 该 过 滤器 处 理 过 的 时 候 执 
行 。 而 该 过 涯 器 的 县 体 过 和 错 就 是 利用 请 求 上 下 文中 的 错误 信息 来 组 成 一 
个 forward 到 API 网 关 /error 错 误 端 点 的 请 求 来 产生 错误 响应 。 





























eSendResponseFilter: 它 的 执行 顺序 为 1000， 是 post 阶 段 最 后 执行 的 
过 小 器。 该 过 滤器 会 检查 请 求 上 下 文中 是 否 包 含 请 求 响应 相关 的 头 信 
轧 、 啊 应 数据 流 或 是 啊 应 体 ， 只 有 在 包含 它们 其 中 一 个 的 时 候 执 行 处 理 
逻辑 。 而 该 过 滤器 的 处 理 逻 辑 就 是 利用 请 求 上 下 文 的 响应 信息 来 组 织 需 
要 发 送 回 客户 端的 啊 应 内 容 。 

下 图 对 上 述 过 滤 占 根据 顺序 、 名 称 、 功 能 、 类 型 做 了 综合 整理 ， 可 
以 帮助 我 们 在 自 定义 过 滤器 或 是 扩展 过 滤器 的 时 候 用 来 参考 并 全 面 地 考 
虑 整个 请 求生 命 周 期 的 处 理 过 程 。 








通过 上 面 请 求生 命 周 期 和 核心 过 小 器 的 介绍 ， 我 们 会 发 现在 核心 过 
滤器 中 并 没有 实现 error 阶 段 的 过 滤器 。 那 么 当 过 滤器 出 现 异常 的 时 候 需 
要 如 何 处 理 呢 ?我 们 不 妨 在 快速 入 门 示 例 中 做 一 个 简单 的 试验 ， 来 看 看 
过 滤 避 中 的 异常 需要 被 如 何 处 理 。 

首先 ， 我 们 答 试 创建 一 个 pre 类 型 的 过 滤器 ， 并 在 该 过 滤器 的 run 方 法 
实现 中 抛 出 一 个 异常 。 比 如 下 面 的 实现 ， 在 run 方法 中 调用 的 
doSomething 方法 将 抛 出 RuntimeException 异 各。 

@Component 

public class ThrowExceptionFilter extends ZuulFilter { 

private static Logger log= 

LoggerFactory.getLogger (ThrowExceptionFilter.class) ; 

Override 

public String filterType () { 

return "Pre ; 

} 

(DOverride 

public int filterOrder () { 

return 0; 

(DOverride 

public boolean shouldFilter () { 

return true; 

1 

(DOverride 

public Object run () { 





log.info ("This is a pre filter,it will throw a RuntimeException") ; 
doSomething () ; 

return null: 

} 

private void doSomething () { 

throw new RuntimeException ("Exist some errors...") ; 


} 


} 

注意 在 该 类 的 定义 上 添加 @Component 注 解 ， 让 Spring 能 够 创建 该 过 
滤 絮 实例， 或 者 也 可 以 像 快 速 入 门 的 例子 中 那样 使 用 @Bean 注 解 在 应 用 
主 类 中 为 其 创建 实例 。 

在 添加 了 上 面 的 过 滤 吉 之后， 我 们 可 以 将 该 应 用 以 及 之 前 的 相关 应 
用 运行 起 来 ， 并 根据 网 关 配 置 的 路 由 规则 访问 服务 接口 ， 比 如 
http://localhost:5555/api-a/hello。 此 时 我 们 会 发 现 ， 在 API 网 关 服 务 的 控 
制 台 中 输出 Dg wr ep on lo 的 过 滤 逻 辑 中 的 日 志 信 息 ， 但 是 并 没 
De 党 信 息 ， 同 时 太 起 的 请 求 也 没有 获得 任何 响应 结 末 。 为 什 

会 出 现 这 样 的 情况 呢 ? 我 们 又 该 如 何在 过 滤 颖 中 人 处 理 异常 呢 ? 翻 授 
ye Cloud Zuul 的 文档 以 及 Netflix Zu 的 Wiki 都 没有 找到 相关 的 内 
， 但 是 这 个 问题 却 久 是 开发 过 程 中 普 训 存在 的 。 所 以 在 本 节 中 ， 我 们 

并 组 分 析 核 必 过 心 过 滤 融 的 异常 处 理 机 制 以 及 如 何在 目 定 义 过 滤器 中 处 理 
已 全 容 

try-catch 处 理 

、 国 想 一 下 ， 我 们 在 上 一 节 中 介绍 的 所 有 核心 过 滤 堪 ， 是 否 记得 有 一 

个 post 过 滤器 SendErrorFilter 是 用 来 处 理 异 常 信息 的 ? ee 
流程 该 过 滤 强 会 处 理 异 常 信息 ， 那 么 这 里 没有 出 现任 何 异 常 信息 说 明 
很 有 可 能 束 是 这 个 过 小 占 没 有 个 执行 。 所以， 不 妨 来 详细 看 看 
SendErrorFilter 的 shouldFilter 函 数 : 

public boolean shouldFilter () { 

RequestContext ctx=RequestContext.getCurrentContext (); 

return ctx.containsKey ("error.status code") && ! 
ctx.getBoolean (SEND_ ERROR FILTER_ RAN ,false) ; 











} 

可 以 看 到 ， 该 方法 的 返回 值 中 有 一 个 重要 的 判断 依据 
ctx.containsKey 〈"error.status_code") ， 也 就 是 说 请 求 上 下 文中 必须 有 
error.status_code 参 数 ， 我 们 实现 的 ThrowExceptionFilter 中 并 没有 设置 
这 个 参数 ， 所 以 自然 不 会 进入 SendErrorFilter 过 滤器 的 处 理 逻 辑 。 那 么 
如 何 使 用 这 个 参数 呢 ? 可 以 看 一 下 route 类 型 的 几 个 过 滤器 ， 由 于 这 些 








过 滤器 会 对 外 发 起 请 求 ， 所 以 肯定 会 有 异常 需要 处 理 ， 比 如 
RibbonRoutingFilter 的 run 方 法 实现 如 下 : 

public Object run () { 

RequestContext context=RequestContext.getCurrentContext () ; 

this.helper.addIgnoredHeaders (); 

try { 

RibbonCommandContext 
commandContext=buildCommandContext (context) ; 

ClientHttpResponse response=forward (commandContext) ; 

setResponse (response) ; 

return response; 

} 

catch (ZuulException ex) { 

context.set (ERROR STATUS CODE,ex.nStatusCode) : 

context.set ("error.message",ex.errorCause) ; 

context.set ("error.exception",ex) ; 

} 

catch (Exception ex) { 

context.set ("error.status_code",HttpServletResponse.SC_INTERNAL S 

context.set ("error.exception",ex) ; 

} 


return null; 


} 

可 以 看 到 ， 整 个 发 起 请 求 的 逻辑 都 采用 了 try-catch 块 处 理 。 在 catch 异 
党 的 处 理 逻 辑 中 并 没有 做 任何 输出 操作 ， 而 是 同 请 求 上 下 文中 添加 了 一 
些 error 相 关 的 参数 ， 主 要 有 下 面 三 个 参数 。 

eerror.status_code: 错误 编码 。 

eerror.exception:Exception 异 第 对 象 。 

eerror.message: 错误 信息 。 

其 中 ，error.status_code 参 数 就 是 SendErrorFilter 过 滤器 用 来 判断 是 否 
需要 执行 的 重要 参数 。 分 析 到 这 里 ， 实 现 异 常 处 理 的 大 致 思路 就 开始 明 
明了 ， 我 们 可 以 参考 RibbonRoutingFilter 的 实现 对 ThrowExceptionFilter 
的 run 方 法 做 一 些 异 常 处 理 的 改造 ， 具 体 如 下 : 

public Object run () { 

log.info ("This is a pre filter,it will throw a RuntimeException") ; 

RequestContext ctx=RequestContext.getCurrentContext (); 

try { 








doSomething () ; 

} catch (Exception e) { 

ctx.set ("error.status_code",HttpServletResponse.SC_INTERNAL_SERYV 
ctX.Set ("error.exception",e) ; 

} 


return null; 


} 

通过 上 面 的 改造 之 后 ， 我 们 再 尝试 访问 之 前 的 接口 ， 这 个 时 候 我 们 
可 以 得 到 如 下 响应 内 容 : 

L 

"timestamp": 1481674980376, 

"status": 500, 

"error": "Internal Server Error", 

"exception": "java.lang.RuntimeException", 

"message": "Exist some errors..." 





} 

此 时 ， 异 常 信息 已 经 被 SendErrorFilter 过 滤器 正常 处 理 并 返回 给 客户 
端 了 ， 同 时 在 网 关 的 控制 台中 也 输出 了 异常 信息 。 从 返回 的 啊 应 信息 
中 ， 可 以 看 到 几 个 之 前 我 们 在 请 求 上 下 文中 设置 的 内 容 ， 它 们 的 对 应 关 
系 如 下 所 示 。 

estatus: 对 应 error.status_code 参 数 的 值 。 

eexception: 对 应 error.exception 参 数 中 Exception 的 类 型 。 

emessage: 对 应 error.exception 参 数 中 Exception 的 message 信 息 。 对 于 
message 的 信息 ， 我 们 在 过 滤器 中 还 可 以 通过 ctx.set ("error.message"," 自 
定义 异 稼 消息 ") ; 来 定义 更 友好 的 错误 信息 。SendErrorFilter 会 优先 取 
error.message 作 为 返回 的 message 内 容 ， 如 果 没 有 的 话 才 会 使 用 Exception 
中 的 message 信 息 。 

ErrorFilter 处 理 

通过 上 面 的 分 析 与 实验 ， 我 们 已 经 知道 如 何在 过 滤器 中 正确 处 理 异 
常 ， 让 错误 信息 能 够 顺利 地 流转 到 后 续 的 SendErrorFilter 过 滤器 来 组 织 
和 输出 。 但 是 ， 即 使 我 们 不 断 强 调 要 在 过 滤 右 中 使 用 try-catch 来 处 理 业 
务 逻 辑 并 各 请 求 上 下 文中 添加 异常 信息 ， 但 是 不 可 控 的 人 为 因素 、 意 料 
之 外 的 程序 因素 等 ， 依 然 会 使 得 一 些 异 稼 从 过 滤器 中 抛 出 ， 对 于 意外 抛 
出 的 异常 义 会 导致 没有 控制 台 输 出 也 没有 任何 啊 应 信息 的 情况 出 现 ， 那 
么 是 否 有 什么 好 的 方法 来 为 这 些 异 背 做 一 个 统一 的 处 理 呢 ? 

这 个 时 候 ， 我 们 就 可 以 用 到 error 类 型 的 过 滤器 了 。 由 于 在 请 求生 命 
周期 的 pre、route、post 三 个 阶段 中 有 异常 抛 出 的 时 候 都 会 进入 error 阶 段 























的 处 理 ， 所 以 可 以 通过 创建 一 个 error 类 型 的 过 滤器 来 捕获 这 些 异常 信 
思 ， 并 根据 这 些 寞 常 信 息 在 请 求 上 下 文中 注入 需要 返回 给 客户 端的 错误 
描述 。 这 里 我 们 可 以 直接 沿用 在 try-catch 处 理 异常 信息 时 用 的 那些 error 
参数 ， 这 样 就 可 以 让 这 些 信息 被 SendErrorFilter 捕 获 并 组 织 成 响应 消息 
返回 给 客户 端 。 比 如 ， 下 面 的 代码 就 实现 了 这 里 所 摘 述 的 一 个 过 滤器 : 

public class ErrorFilter extends ZuulFilter { 

Logger log=LoggerFactory.getLogger (ErrorFilter.class) ; 

(DOverride 

public String filterType () { 

return "error"; 

} 

(DOverride 

public int filterOrder () { 

return 10; 

} 

(OOverride 

public boolean shouldFilter () { 

return true; 

} 

(DOverride 

public Object run () { 

RequestContext ctx=RequestContext.getCurrentContext (); 

Throwable throwable=ctx.getThrowable () ; 

log.error ("this is a ErrorFilter 
{}",throwable.getCause () .getMessage () ) ; 

ctx.set ("error.status_code",HttpServletResponse.SC_INTERNAL_SERYV 

ctx.set ("error.exception",throwable.getCause () ) ; 

return null; 


} 


} 

在 将 该 过 滤器 加 入 API 网 关 服 务 之 后 ， 我 们 可 以 答 试 使 用 之 前 介绍 
try-catch 处 理 时 实现 的 ThrowExceptionFilter 〈 不 包含 异常 处 理 机 制 的 代 
人 码 ) ， 让 该 过 滤器 能 够 抛 出 异常 。 这 个 时 候 我 们 再 通过 API 网 关 来 访问 
服务 接口 。 此 时 ， 我 们 残 可 以 在 控制 台中 看 到 ThrowExceptionFilter 过 滤 
器 抛 出 的 民利 信息 ， 并 且 请 求 啊 应 中 也 能 获得 如 下 的 错误 信息 内 容 ， 而 
不 是 什么 信息 都 没有 的 情况 了 。 

{ 

















"timestamp": 1481674993561, 

"status": 500, 
"error": "Internal Server Error", 
"exception": "java.lang. RuntimeException", 
"message": "Exist some errors.. 


} 

不 足 与 优化 

到 这 里 ， 我 们 已 经 基本 掌握 了 在 核心 过 滤器 处 理 馆 辑 之 下 ， 对 自 定 
义 过 滤器 中 处 理 异 常 的 两 种 基本 解决 方法 : 一 种 是 通过 在 各 个 阶段 的 过 
小 右 中 增加 try-catch 块 ， 实现 过 滤器 内 部 的 异常 处 理 ， 男 一 种 是 利用 
error 类 型 过 滤器 的 生命 周期 特性 ， 和 集中 人 处理 pre、route、post 阶 段 抛 出 的 
异常 信息 。 通 常情 况 下 ， 我 们 可 以 将 这 两 种 手段 同时 使 用 ， 其 中 第 一 种 
是 对 开发 人 员 的 基本 要 求 ， 而 第 二 种 是 对 第 一 种 处 理 方 式 的 补充 ， 以 防 
止 意外 情况 的 发 生 。 

这 样 的 异常 处 理 机 制 看 似 已 经 完美 ， 但 是 如 果 在 多 一 些 应 用 实践 或 
源码 分 析 之 后 ， 我 们 会 发 现 依 然 存 在 一 些 不 足 。 下 和 面 ， 我 们 不 妨 跟 着 源 
码 来 看 看 ， 到 底 上 面 的 方案 还 有 哪些 不 足 之 处 需要 注意 和 进一步 优化 。 
先 来 看 看 外 部 请 求 到 达 API 网 关 服 务 之 后 ， 各 个 阶段 的 过 滤器 是 如 何 进 
行 调度 的 : 

try { 

preRoute (); 

} catch (ZuulExceptione) { 

error (e) ; 

postRoute (); 

return; 

} 

try { 

route (); 

} catch (ZuulException e) { 

error (e) ; 

postRoute () ; 

return; 

} 

try { 

postRoute (); 

} catch (ZuulException e) { 

error (e) ; 














return; 


} 

上 面 的 代码 源 自 com.netflix.zuul.http.ZuulServlet 的 service 方 法 实现 ， 
它 定义 了 Zuul 处 理 外 部 请 求 过 程 时 ， 各 个 类 型 过 滤器 的 执行 逻辑 。 从 代 
人 码 中 我 们 可 以 看 到 三 个 try-catch 块 ， 它 们 依次 分 别 代表 了 pre、route、 
post 三 个 阶段 的 过 滤器 调用 。 在 catch 的 异常 处 理 中 我 们 可 以 看 到 它们 都 
会 被 error 类 型 的 过 小 器 进行 处 理 (之 前 使 用 error 过 滤器 来 定义 统一 的 异 
常 处 理 也 正 是 利用 了 这 个 特性 ) ;”error 类 型 的 过 滤器 处 理 完毕 之 后 ， 除 
了 来 自 post 阶 段 的 异常 之 外 ， 都 会 再 被 post 过 滤器 进行 处 理 。 所 以 ， 上 
面 代码 中 各 个 处 理 阶段 的 逻辑 如 下 图 所 示 : 


通过 图 中 的 分 析 ， 我 们 可 以 看 到 ， 对 于 从 post 过 滤器 中 抛 出 异常 的 
情况 ， 在 经 过 error 过 滤 右 处 理 之 后 ， 束 没有 其 他 类 型 的 过 滤器 来 接手 
了 ， 这 就 是 使 用 之 前 所 述 方案 存在 不 足 之 处 的 根源 。 回 想 一 下 之 前 实现 
的 两 种 异常 处 理 方法 ， 其 中 非常 核心 的 一 点 是 ， 这 两 种 处 理 方法 都 在 异 
常 处 理 时 问 请 求 上 下 文中 添加 了 一 系列 的 error.* 参 数 ， 而 这 些 参数 真正 
起 作用 的 地 方 是 在 post 阶 段 的 SendErrorFilter， 在 该 过 滤器 中 会 使 用 这 些 
参数 来 组 织 内 容 返回 给 客户 端 。 而 对 于 post 阶 段 抛 出 异常 的 情况 下 ， 由 
error 过 滤器 处 理 之 后 并 不 会 再 调用 post 阶段 的 请 求 ， 自 然 这 些 error.* 参 
数 也 就 不 会 被 SendErrorFilter 消 费 输 出 。 所 以 ， 如 果 我 们 在 自 定 义 post 过 
小 右 的 时 候 ， 没 有 正确 处 理 异常 ， 就 依然 有 可 能 出 现 日 志 中 没有 异常 但 
请 求 啊 应 内 容 为 空 的 问题 。 我 们 可 以 通过 将 之 前 ThrowExceptionFilter 的 
filterType 修 改 为 post 来 验证 这 个 问题 的 存在 ， 注 意 去 掉 try-catch 块 的 处 
理 ， 让 它 能 够 抛 出 异常 。 

解决 上 述 问题 的 方法 有 很 多 种 ， 最 直接 的 是 我 们 可 以 在 实现 error 过 
小 右 的 时 候 ， 直 接 组 织 结果 返回 束 能 实现 效果 。 但 是 这 样 做 的 缺点 也 很 
明显 ， 对 于 错误 信息 组 织 和 返回 的 代码 实现 会 存在 多 份 ， 这 样 非常 不 利 
于 日 后 的 代码 维护 工作 。 所 以 为 了 保持 对 异常 返回 处 理 逻 辑 的 一 致 性 ， 
我 们 还 是 希望 将 post 过 滤器 抛 出 的 异常 交 给 SendErrorFilter 来 处 理 。 

在 前 文中 ， 我 们 已 经 实现 了 一 个 ErrorFilter 来 捕获 pre、route、post 过 
滤 右 抛 出 的 异常 ， 并 组 织 error.* 参 数 保存 到 请 求 的 上 下 文中 。 由 于 我 们 
的 目标 是 治 用 SendErrorFilter， 这 些 error.* 人 参数 依然 对 我 们 有 用 ， 所 以 可 
以 继续 沿用 该 过 滤器 ， 让 它 在 post 过 滤器 抛 出 异常 的 时 候 ， 继 续 组 织 
error.* 参 数 ， 只 是 这 里 我 们 已 经 无 法 将 这 些 erTror.# 人 参数 再 传递 给 
SendErrorFilter 过 滤器 来 处 理 了 。 所 以 ， 我 们 需要 在 ErrorFilter 过 滤器 之 
后 再 定义 一 个 error 类 型 的 过 滤器 ， 让 它 来 实现 SendErrorFilter 的 功能 ， 
但 是 这 个 error 过 滤器 并 不 需要 处 理 所 有 出 现 异 常 的 情况 ， 它 仅 对 post 过 








滤器 抛 出 的 异常 有 效 。 根 据 上 面 的 思路 ， 我 们 完全 可 以 创建 一 个 继承 自 
SendErrorFilter 的 过 滤器 ， 复 用 它 的 run 方 法 ， 然 后 重 写 它 的 类 型 、 顺 序 
以 及 执行 条 件 ， 实 现 对 原 有 远 辑 的 复 用 ， 具 体 实现 如 下 : 

@Component 

public class ErrorExtFilter extends SendErrorFilter { 

(DOverride 

public String filterType () { 

return "error"; 

} 

(DOverride 

public int filterOrder () { 

return 30; // 大 于 ErrorFilter 的 值 

} 

(DOverride 

public boolean shouldFilter () { 

WTODO 判断 : 仅 处 理 来 自 post 过 滤 右 引起 的 异常 

return true; 


} 


} 

到 这 里 ， 我 们 在 过 滤器 调度 上 的 实现 思路 已 经 很 清晰 了 ， 但 是 义 有 
一 个 问题 出 现在 我 们 面前 : 怎么 判断 引起 异常 的 过 滤器 来 自 什 么 阶段 
呢 ?shouldFilter 方 法 该 如 何 实现 ， 对 于 这 个 问题 ， 我 们 第 一 反应 会 寄 希 
望 于 请 求 上 下 文 RequestContext 对 象 ， 可 是 在 查阅 文档 和 源码 后 发 现 其 
中 并 没有 存储 异常 来 源 的 内 容 ， 所 以 我 们 不 得 不 扩展 原来 的 过 滤器 处 理 
逻辑 。 当 有 异常 抛 出 的 时 候 ， 记 录 下 抛 出 异常 的 过 滤器 ， 这 样 我 们 就 可 
以 在 ErrorExtFilter 过 滤器 的 shouldFilter 方 法 中 获取 并 以 此 判断 异常 是 否 
来 自 post 阶 段 的 过 滤器 了 。 

为 了 扩展 过 滤器 的 处 理 逻 辑 ， 为 请 求 上 下 文 增加 一 些 自 定 义 属性 ， 
我 们 需要 深入 了 解 Zuul 过 滤器 的 核心 处 理 器 : 
com.netflix.zuul.FilterProcessor。 访 类 中 定义 了 下 面 列 出 的 过 滤 喜 调用 和 
处 理 相 关 的 核心 方法 。 

egetInstance〈) : 该 方法 用 来 获取 当前 处 理 右 的 实例 。 

esetProcessor (FilterProcessor ”processor) : 该 方法 用 来 设置 处 理 器 
实例 ， 可 以 使 用 此 方法 来 设置 自 定义 的 处 理 器 。 

eprocessZuulFilter (ZuulFilter filter) : 该 方法 定义 了 用 来 执行 filter 
的 具体 逻辑 ， 包 括 对 请 求 上 下 文 的 设置 ， 判 断 是 否 应 该 执行 ， 执 行 时 一 
些 异常 的 处 理 等 。 














egetFiltersByType (String filterType) : 该 方法 用 来 根据 传 入 的 
filterType 获取 API 网 关中 对 应 类 型 的 过 滤器 ， 并 根据 这 些 过 滤器 的 
filterOrder 从 小 到 大 排序 ， 组 织 成 一 个 列表 返回 。 

erunFilters (String sSType) : 该 方法 会 根据 传 入 的 filterType 来 调用 
getFiltersByType (String filterType) 获取 排序 后 的 过 滤器 列表 ， 然 后 轮 
询 这 些 过 滤器 ， 并 调用 processZuulFilter (ZuulFilter filter) 来 依次 执行 
全 

epreRoute () : 调用 runFilters ("pre") 来 执行 所 有 pre 类 型 的 过 滤 
器 


髓 。 
epostRoute () : 调用 runFilters ("post") 来 执行 所 有 post 类 型 的 过 滤 
En 


eroute () : 调用 runFilters ("route") 来 执行 所 有 route 类 型 的 过 滤 


eerror () : 调用 runFilters 《"error") 来 执行 所 有 error 类 型 的 过 滤 





根据 之 前 的 设计 ， 可 以 直接 扩展 processZuulFilter (ZuulFilter 
filter) ， 当 过 滤器 执行 抛 出 异常 的 时 候 ， 我 们 捕获 它 ， 并 同 请 求 上 下 中 
记录 一 些 信息 。 比 如 下 面 的 具体 实现 : 

public class DidiFilterProcessor extends FilterProcessor { 

(DOverride 

public Object processZuulFilter (ZuulFilter filter) throws 
ZuulException { 

try { 

return super.processZuulFilter (filter) ; 

} catch (ZuulException e) { 

RequestContext ctx=RequestContext.getCurrentContext (); 

ctx.set ("failed .filter",filter) ; 

throw e; 

} 

} 





} 

在 上 面 代码 的 实现 中 ， 我 们 创建 了 一 个 FilterProcessor 的 子 类 ， 并 重 
写 了 processZuulFilter (ZuulFilter filter) ， 昌 然 主 逻辑 依然 使 用 了 父 类 
的 实现 ， 但 是 在 最 外 层 ， 我 们 为 其 增加 了 异常 捕获 ， 并 在 异常 处 理 中 为 
请 求 上 下 文 添 加 了 failed.filter 属 性 ， 以 存储 抛 出 异常 的 过 滤器 实例 。 在 
实现 了 这 个 扩展 之 后 ， 我 们 也 就 可 以 完善 之 前 ErrorExtFilter 中 的 
shouldFilter〈) 方法 了 ， 通 过 从 请 求 上 下 文中 获取 该 信息 做 出 正确 的 判 











岂 ， 有 具体 实现 如 下 : 

@Component 

public class ErrorExtFilter extends SendErrorFilter { 

(DOverride 

public String filterType () { 

return "error"; 

} 

(DOverride 

public int filterOrder () { 

return 30; // 大 于 ErrorFilter 的 值 

} 

(DOverride 

public boolean shouldFilter () { 

RequestContext ctx=RequestContext.getCurrentContext (); 

ZuulFilter failedFilter= (ZuulFilter) ctx.get ("failed.filter") ; 

/判断 : 仅 处 理 来 自 post 过 滤器 引起 的 异常 

if (failedFilter !=null &&r 
failedFilter.filterType () .equals ("post") ) { 

return true; 

} 

return false; 


} 


} 

到 这 里 ， 我 们 的 优化 任务 还 没有 完成 ， 因 为 扩展 的 过 滤器 处 理 类 并 
还 没有 和 生效。 最后， 需要 在 应 用 主 类 中 ， 通 过 调用 
FilterProcessor.setProcessor (new DidiFilterProcessor () ) ; 方法 来 启用 
目 定义 的 核心 处 理 器 以 完成 我 们 的 优化 目标 。 

自 定义 异常 信息 

在 实现 了 对 自 定义 过 小 器 中 的 异常 处 理 之 后 ， 实 际 应 用 到 业务 系统 
中 时 ， 往 往 默 认 的 错误 信息 并 不 符合 系统 设计 的 啊 应 格式 ， 那 么 我 们 就 
需要 对 返回 的 异常 信息 进行 定制 。 对 于 如 何 定 制 这 个 错误 信息 有 很 多 种 
方法 可 以 实现 。 最 直接 的 是 ， 可 以 编写 一 个 自 定义 的 post 过 滤 絮 来 组 织 
错误 结果 ， 该 方法 实现 起 来 简单 粗暴 ， 完 全 可 以 参考 SendErrorFilter 的 
实现 ， 然 后 直接 组 织 请 求 啊 应 结果 而 不 是 forward 到 j/error 端 点 ， 只 是 使 
用 该 方法 时 需要 注意 : 为 了 蔡 代 SendErrorFilter， 还 需要 禁 
SendErrorFilter 过 滤器 ， 禁 用 的 配置 方法 在 后 文中 会 详细 介绍 。 

那么 如 果 不 采 用 重 写 过 滤器 的 方式 ， 依 然 想 要 使 用 SendErrorFilter 来 





























处 理 异常 返回 的 话 ， 我 们 要 如 何 定制 返 回 的 啊 应 结果 呢 ? 这 个 时 候 ， 我 
们 的 关注 点 就 不 能 放 在 Zuu 的 过 滤器 上 了 ， 因 为 错误 信息 的 生成 实际 上 
并 不 是 由 Spring Cloud Zuul 完 成 的 。 我 们 在 介绍 SendErrorFilter 的 时 候 提 
到 过 ， 它 会 根据 请 求 上 下 中 保存 的 错误 信息 来 组 织 一 个 forward 到 /error 
端点 的 请 求 来 获取 错误 啊 应 ， 所 以 我 们 的 扩展 目标 转移 到 了 对 /error 闹 
点 的 实现 。 

/error 端点 的 实现 来 源 于 Spring Boot 的 
org.springframework.boot.autoconfigure.web.BasicErrorController， 它 的 具 
体 定义 如 下 : 

(DReduestMapping 

(@OResponseBody 

public ResponseEntity<Map<String,Object>> error (HttpServletRequest 
request) { 

Map<String,Object> body=getErrorAttributes (request, 

isIncludeStackTrace (request,MediaType.ALL) ) ; 

HttpStatus status=getStatus (request) ; 

return new ResponseEntity<Map<String,Object>> (body,status) ; 











} 

从 源码 中 可 以 看 到 ， 它 的 实现 非常 简单 ， 通 过 调用 getErrorAttributes 
方法 来 根据 请 求 参数 组 织 错误 信息 的 返回 结果 ， 而 这 里 的 
getErrorAttributes 方 法 会 将 具体 组 织 逻 辑 委 托 给 
org.springframework.boot.autoconfigure.web.ErrorAttributes 接 口 提供 的 
getErrorAttributes 来 实现 。 在 Spring Boot 的 自动 化 配置 机 制 中 ， 默 认 会 采 
用 org.springframework.boot.autoconfigure.web.DefaultErrorAttributes 作 为 
该 接口 的 实现 。 如 下 代码 所 示 ， 在 定义 Error 处 理 的 目 动 化 配置 中 ， 该 接 
口 的 默认 实现 采用 了 @ConditionalOnMissingBean 修 饰 ， 说 明 
DefaultErrorAttributes 对 象 实例 仅 在 没有 ErrorAttributes 接 口 的 实例 时 才 
会 被 创建 来 使 用 ， 所 以 我 们 只 需要 自己 编写 一 个 自 定 义 的 ErrorAttributes 
接口 实现 类 ， 并 创建 它 的 实例 惑 能 蔡 代 这 个 默认 的 实现 ， 从 而 达到 目 定 
义 错误 信息 的 效果 了 。 

@ConditionalOnClass ({ Servlet.class,DispatcherServlet.class } ) 

(@OConditional OnWebApplication 

@AutoConfigureBefore (WebMvcAutoConfiguration.class) 

@Configuration 

public class ErrorMvcAutoConfiguration { 

(OAutowired 

private ServerProperties properties; 











Bean 

@ConditionalOnMissingBean (value=ErrorAttributes.class,search=Searc 
public DefaultErrorAttributes errorAttributes () { 

return new DefaultErrorAttributes (); 


} 


} 

举 个 简单 的 例子 ， 比 如 我 们 不 希望 将 exception 属性 返回 给 客户 端 ， 
那么 就 可 以 编写 一 个 自 定 义 的 实现 ， 它 可 以 基于 
DefaultErrorAttributes， 然 后 重 写 getErrorAttributes 方 法 ， 从 原来 的 结果 
中 将 exception 移 除 即 可 ， 具 体 实现 如 下 : 

public class DidiErrorAttributes extends DefaultErrorAttributes { 

(DOverride 

public Map<String,Object> getErrorAttributes ( 

RequestAttributes requestAttributes,boolean includeStackTrace) { 

Map<String,Object> 
result=super.getErrorAttributes (requestAttributes,includeStackTrace) ; 

result.remove ("exception") ; 

return result; 


} 


} 

最 后 ， 为 了 让 自 定义 的 错误 信息 生成 逻辑 生效 ， 需 要 在 应 用 主 类 中 
加 入 如 下 代码 ， 为 其 创建 实例 来 苦 代 默认 的 实现 : 

Bean 

public DefaultErrorAttributes errorAttributes () { 

return new DidiErrorAttributes (); 


} 
通过 上 面 介绍 的 方法 ， 我 们 就 能 基于 Zuul 的 核心 过 滤 峰 来 灵活 地 上 自 
定义 错误 返回 信息 ， 以 满足 实际 应 用 系统 的 啊 应 格式 了 。 


林木 -十 > E 口 


不 论 是 核心 过 滤器 还 是 自 定义 过 滤器 ， 只 要 在 API 网 关 应 用 中 为 它们 
创建 了 实例 ， 那 么 默认 情况 下 ， 它 们 都 是 启用 状态 的 。 那 么 如 果 有 些 过 
滤 右 我 们 不 想 使 用 了 ， 如 何 禁 用 它们 呢 ?” 大 多 情况 下 初 识 Zuul 的 使 用 者 
第 一 反应 就 是 通过 重 写 shouldFilter 好 辑 ， 让 它 返 回 false， 这 样 该 过 滤器 
对 于 任何 请 求 都 不 会 被 执行 ， 基 本 实现 了 对 过 滤器 的 禁用 。 但 是 ， 对 于 














自 定 义 过 滤器 来 说 似乎 是 实现 了 过 滤器 不 生效 的 功能 ， 但 是 这 样 的 做 法 
缺乏 灵活 性 。 由 于 直接 要 修改 过 滤器 逻辑 ， 我 们 不 得 不 重新 编译 程序 ， 
并 且 如 果 该 过 小 器 在 未 来 一 段 时 间 还 有 可 能 被 启用 的 时 候 ， 那 么 就 又 得 
修改 代码 并 编译 程序 。 同 时 ， 对 于 核心 过 小 占 来 襄 ， 束 更 为 抹 烦 ， 我 们 
不 得 不 获取 源码 来 进行 修改 和 编译 。 

实际 上 ， 在 Zuul 中 特别 提供 了 一 个 参数 来 禁用 指定 的 过 滤器 ， 该 参 
数 的 配置 格式 如 下 : 

zuul.<SimpleClassName>.<filterT'ype>.disable=true 

其 中 ，<SimpleClassName> 代 表 过 滤器 的 类 名 ， 比 如 快速 入 门 示 例 中 
的 AccessFilter;<filterType> 代 表 过 滤器 类 型 ， 比 如 快速 入 门 示例 中 
AccessFilter 的 过 滤器 类 型 pre。 所 以 ， 如 果 我 们 想 要 禁用 快速 入 门 示 例 
中 的 AccessFilter 过 滤器 ， 只 需要 在 application.properties 配 置 文件 中 增加 
如 下 配置 即 可 : 

zuul.AccessFilter.pre.disable=true 

该 参数 配置 除了 可 以 对 自 定义 的 过 滤器 进行 禁用 配置 之 外 ， 很 多 时 
候 可 以 用 它 来 禁用 Spring Cloud Zuul 中 默认 定义 的 核心 过 滤器 。 这 样 我 
们 束 可 以 扫 开 Spring Cloud Zuul 目 带 的 那 套 核心 过 滤器 ， 实 现 一 套 更 符 
合 我 们 实际 需求 的 处 理 机 制 。 

通过 本 节 对 异常 处 理 的 介绍 ， 也 许 这 些 方法 并 一 定 完全 适用 读者 所 
接触 的 实际 系统 ， 但 是 通过 这 些 分 析 可 以 帮助 我 们 进一步 理解 Zuul 过 渡 
器 的 运行 机 制 ， 帮 助 我 们 基于 Spring Cloud Zuul 去 实现 更 适合 自身 系统 
的 API 网 关 服 务 。 

















在 微服 务 架 构 中 ， 由 于 API 网 关 服 务 担负 着 外 部 访问 统一 入 口 的 重 
任 ， 它 同 其 他 应 用 不 同 ， 任 何 关 闭 应 用 和 重启 应 用 的 操作 都 会 使 系统 对 
外 服务 停止 ， 对 于 很 多 7x24 小 时 服务 的 系统 来 说 ， 这 样 的 情况 是 绝对 不 
被 多 许 的 。 所 以 ， 作 为 最 外 部 的 网 关 ， 它 必须 具备 动态 更 新 内 部 人 逻辑 的 
能 力 ， 比 如 动态 修改 路 由 规则 、 动 态 添加 /删除 过 滤器 等 。 

通过 Zuul 实 现 的 API 网 关 服 务 当然 也 具备 了 动态 路 由 和 动态 过 滤器 的 
能 力 。 我 们 可 以 在 不 重启 API 网 关 服 务 的 前 提 下 ， 为 其 动态 修改 路 由 规 
则 和 添加 或 删除 过 小 器。 下 面 我 们 分 别 来 看 看 如 何 通 过 Zuul 来 实现 动态 
API 网 关 服 务 。 











动态 时 








通过 之 前 对 请 求 路 由 的 详细 介绍 ， 我 们 可 以 发 现 对 于 路 由 规则 的 控 
制 几 乎 都 可 以 在 配置 文件 application.properties 或 application.yaml 中 完 
成 。 既 然 这 样 ， 对 于 如 何 实 现 Zuul 的 动态 路 由 ， 我 们 很 自然 地 会 将 它 与 
Spring Cloud Config 的 动态 刷新 机 制 联系 到 一 起 。 只 需 将 API 网 关 服 务 的 
配置 文件 通过 Spring Cloud Config 连 接 的 Git 仓 库存 储 和 管理 ， 我 们 就 能 
轻松 实现 动态 刷新 路 由 规则 的 功能 。 

在 介绍 如 何 具体 实现 API 网 关 服 务 的 动态 路 由 之 前 ， 我 们 首先 需要 一 
个 连接 到 Git 仓 库 的 分 布 式 配置 中 心 config-server 应 用 。 如 果 还 没有 搭建 
过 分 布 式 配 置 中 心 的 话 ， 建 议 先 阅读 第 8 章 的 内 容 ， 对 分 布 式 配 置 中 心 
的 运作 机 制 有 一 个 基础 的 了 解 ， 并 构建 一 个 config-server 应 用 ， 以 配合 
完成 下 面 的 内 容 。 

在 具备 了 分 布 式 配置 中 心 之 后 ， 为 了 方便 理解 ， 我 们 重新 构建 一 个 
API 网 关 服 务 ， 访 服务 的 配置 中 心 不 再 配置 于 本 地 工程 中 ， 而 是 从 
config-server 中 获取 ， 构 建 过 程 如 下 所 示 。 

e 创 建 一 个 基础 的 Spring Boot 工 程 ， 命 名 为 api-gateway-dynamic- 
route。 

e 在 pom.xml 中 引入 对 zuul、eureka 和 config 的 依赖 ， 有 具体 内 容 如 下 : 

<parent> 

<groupId>org.Springframework.boot</groupId> 

<artifactId>spring-boot-starter-parent</artifactId> 

<version>1.3.7.RELEASE</version> 








<relativePath/> 

</parent> 

<dependencies> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-zuul</artifactId> 

</dependency> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-eureka</artifactId> 

</dependency> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-config</artifactId> 

</dependency> 

</dependencies> 

<dependencyManagement> 

<dependencies> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-dependencies</artifactId> 

<version>Brixton.SR5</version> 

<type>pom</type> 

<scope>import</scope> 

</dependency> 

</dependencies> 

</dependencyManagement> 

e 在 /resource 目 录 下 创建 配置 文件 bootstrap.properties， 并 在 该 文件 中 
指定 config-server 和 eureka-server 的 具体 地 址 ， 以 获取 应 用 的 配置 文件 
和 实现 服务 注册 与 发 现 。 

Spring.application.name=api-gateway 

server.port=5556 

spring.cloud.config.uri=http://localhost:7001/ 

eureka.client.serviceUTrl.defaultZone=http://localhost:1111/eureka/ 

e 创 建 用 来 局 动 API 网 关 的 应 用 主 类 。 这 里 我 们 需要 使 用 
(@RefreshScope 注 解 来 将 Zuul 的 配置 内 容 动 态 化 ， 具 体 实 现 如 下 : 

@EnableZuulProxy 


SpringCloudApplication 
public class Application { 
public static void main (String[largs) { 
new 
SpringApplicationBuilder (Application.class) .web (true) .run Cargs) ; 
} 


Bean 

@RefreshScope 
@ConfigurationProperties ("zuul") 
public ZuulProperties zuulProperties () { 
return new ZuulProperties (); 


} 


} 

e 在 完成 了 所 有 程序 相关 的 编写 之 后 ， 我 们 还 需要 在 Git 仓 库 中 增加 
网 关 的 配置 文件 ， 取 名 为 api-gateway.properties。 在 配置 文件 中 ， 我 们 为 
API 网 关 服 务 预 定义 以 下 路 由 规则 ， 比 如 : 

zuul.routes.service-a.path=/service-a/** 

zuul.routes.service-a.serviceld=hello-service 

zuul.routes.service-b.path=/service-b/** 

zuul.routes.service-b.url=http://localhost:8001/ 

对 于 API 网 关 服 务 在 Git 仓库 中 的 配置 文件 名 称 完 全 取决 于 网 天 应 
用 配置 文件 bootstrap.properties 中 spring.application.name 属性 的 配置 
值 。 由 于 本 章 我 们 主要 介绍 API 网 关 的 使 用 ， 所 以 这 里 省 略 了 关于 label 
和 profile 的 配置 ， 默 认 会 使 用 master 分 文 和 default 配 置 文件 ， 更 细致 的 配 
置 方式 读者 可 得 阅 第 8 草 介 绍 的 内 容 。 

测试 与 验证 

在 完成 了 上 述 内 容 之 后 ， 我 们 可 以 将 ”config-server、eureka-server、 
api-gateway-dynamic-route ”以 及 配置 文件 中 路 由 规则 指 同 的 具体 服务 ， 
比如 hello-service ”启动 起 来 。 此 时 ,在 ” API 网 关 应 用 api-gateway- 
dynamic-route 的 控制 台中 ， 我 们 可 以 看 到 它 输出 了 从 config-server 中 获取 
配置 文件 过 程 的 日 志 人 信息， 根据 这 些 信息 ， 可 以 判断 获取 配置 信息 的 路 
径 等 内 容 是 否 正 确 。 有 共 体 输出 内 容 如 下 所 示 : 

c.c.C.ConfigServicePropertySourceLocator : Fetching config from server 

















at: 

http://localhost:7001/ 

c.c.C.ConfigServicePropertySourceLocator : Located environment: 
name=api-gateway, 


profiles= 
[default],label=master,version=1dab6126ca2972c5409fcb089934b057cf2bf77 

b.c.PropertySourceBootstrapConfiguration : Located property source: 

CompositePropertySource[name='configService',propertySources= 
[MapPropertySource 

[name='overrides'],MapProperty9ource 

[name='http://git.oschina.net/didispace/SpringCloud- 
Learning/spring_cloud_ in_action 

/config-repo/api-gateway.properties']]] 

com.didispace.Application : No active profile set,falling 
back to 

default profiles: default 

在 api-gateway-dynamic-route 启动 完成 之 后 ， 可 以 通过 对 API 网 关 服 
务 调 用 /routes 接 口 来 获取 当前 网 关上 的 路 由 规则 ， 根 据 上 述 配置 我 们 可 
以 得 到 如 下 返回 信息 : 

{ 

"/service-a/**": "hello-service", 

"/service-b/**": "http://localhost:8001/" 


} 

我 们 可 以 先 尝 试 着 通过 上 述 路 由 规则 访问 一 下 对 应 路 由 服务 提供 的 
接口 ， 验 证 当前 的 路 由 规则 是 否 生 效 。 接 着 ， 我 们 开始 尝试 动态 修改 这 
些 路 由 规则 ， 只 需要 以 下 两 步 。 

e 修 改 Git 仓 库 中 的 api-gateway.properties 配 置 文件 ， 比 如 ， 将 service-a 
路 由 规则 的 path 修改 为 /aaa/**， 并 把 service-b 的 路 由 规则 从 url 修改 为 
servicelId 方 式 。 具 体 配置 如 下 : 

zuul.routes.service-a.path=/aaa/** 

zuul.routes.service-a.serviceld=hello-service 

zuul.routes.service-b.path=/service-b/** 
zuul.routes.service-b.url=hello-service 

e 在 修改 完 配 置 文件 之 后 ， 将 修改 内 容 推 送 到 远程 仓库 。 然 后 ， 通 过 
向 api-gateway-dynamic-route 的 /refresh 接 口 发 送 POST 请 求 来 刷新 配置 信 
恩 。 当 配置 文件 有 修改 的 时 候 ， 该 接口 会 返回 被 修改 的 属性 名 称 ， 根 据 
上 面 的 修改 ， 我 们 会 得 到 如 下 返回 信息 : 

[ 

"zuul.routes.service-b.serviceld", 

"zuul.routes.service-b.url", 

"zuul.routes.service-a.path" 

















] 

由 于 修改 了 service-b 路 由 的 ur 方式 为 serviceId 方 式 ， 相 当 于 删除 了 url 
参数 配置 ,增加 了 serviceId ”参数 配置 ， 所 以 这 里 会 出 现 两 条 关于 
service-b 路 由 的 变更 信息 。 

到 这 里 ， 我 们 就 已 经 完成 了 路 由 规则 的 动态 刷新 ， 可 以 继续 通过 
| 由 天 服 务 的 outes 搂 口 来 查看 当前 的 所 有 路 由 规则 ， 该 接口 将 返回 

下 信息 : 

{ 


"/aaa/**". "hello-service", 
"/service-b/**". "hello-service" 


} 

从 Mroutes 接 口 的 信息 中 我 们 可 以 看 到 ， 路 由 service-a 的 匹配 表达 式 被 
修改 成 了 /aaa/*x*， 而 路 由 service-b 的 映射 目标 从 原来 的 物理 地 址 
http://localhost:8001/ 修 改 成 了 hello-service 服 务 。 

通过 本 节 对 动态 路 由 加 载 内 容 的 介绍 ， 我 们 可 以 看 到 ， 通 过 Zuul 构 
建 的 API 网 和 天 服务 对 于 动态 路 由 的 实现 总 体 上 来 说 还 是 非常 简单 的 。 美 
中 不 足 的 一 点 是 ，Spring Cloud Config 并 没有 UI 管理 界面 ， 我 们 不 得 不 
通过 Git 客 户 端 来 进行 修改 和 配置 ， 所 以 在 使 用 的 时 候 并 不 是 特别 方 
下 当然 有 条 件 的 团队 可 以 自己 开发 一 套 UI 界 面 来 帮助 管理 这 些 路 由 规 
则 。 
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既然 通过 Zuul 构建 的 API 网 关 服 务 能 够 轻松 地 实现 动态 路 由 的 加 
载 ， 那 么 对 于 API 网 关 服 务 的 另外 一 大 重要 功能 一 请 求 过 滤器 的 动态 加 
载 自 然 也 不 能 放 过 ， 只 是 对 于 请 求 过 滤器 的 动态 加 载 与 请 求 路 由 的 动态 
加 载 在 实现 机 制 上 会 有 所 不 同 。 这 个 不 难 理解 ， 通 过 之 前 介绍 的 请 求 路 
由 和 请 求 过 滤 的 示例 ， 我 们 可 以 看 到 请 求 路 由 通过 配置 文件 就 能 实现 ， 
而 请 求 过 滤 则 都 是 通过 编码 实现 。 所 以 ， 对 于 实现 请 求 过 滤器 的 动态 加 
载 ， 我 们 需要 借助 基于 JVM 实 现 的 动态 语言 的 帮助 ， 比 如 Groovy。 

下 面 ， 我 们 将 通过 一 个 简单 的 示例 来 演示 如 何 构建 一 个 具备 动态 加 
载 Groovy 过 滤器 能 力 的 API 网 关 服 务 的 详细 步骤。 

e 创 建 一 个 基础 的 Spring Boot 工 程 ， 命 名 为 api-gateway-dynamic- 
filter。 

e 在 pom.xml 中 引入 对 zuul、eureka 和 groovy 的 依赖 ， 有 具体 内 容 如 下 : 

<parent> 

<groupId>org.Springframework.boot</groupId> 








<artifactId>spring-boot-starter-parent</artifactId> 

<version>1.3.7.RELEASE</version> 

<relativePath/> 

</parent> 

<dependencies> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-zuul</artifactId> 

</dependency> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-eureka</artifactId> 

</dependency> 

<dependency> 

<groupld>org.codehaus.groovy</groupld> 

<artifactId>groovy-all</artifactId> 

</dependency> 

</dependencies> 

<dependencyManagement> 

<dependencies> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-dependencies</artifactId> 

<version>Brixton.SR5</version> 

<type>pom</type> 

<scope>import</scope> 

</dependency> 

</dependencies> 

</dependencyManagement> 

e 在 /resource 目 录 下 创建 配置 文件 application.properties， 并 在 该 文件 
中 设置 API 网 天 服务 的 应 用 名 和 服务 端口 写 ， 以 及 指定 eureka-server 的 具 
体 地 址 。 同 时 ， 再 配置 一 个 用 于 测试 的 路 由 规则 ， 我 们 可 以 用 之 前 章节 
实现 的 helloservice 为 例 。 具 体 配 置 内 容 如 下 : 

spring.application.name=api-gateway 

server.port=5555 

eureka.client.serviceUTrl.defaultZone=http://localhost:1111/eureka/ 

zuul.routes.hello.path=/hello-service/** 





zuul.routes.hello.serviceld=hello-service 

到 这 里 一 个 基础 的 API 网 关 服 务 已 经 构建 完成 ， 下 面 我 们 来 为 它 增 加 
动态 加 载 过 滤器 的 功能 。 

e 为 了 方便 使 用 ， 我 们 先 目 定义 一 些 用 来 配置 动态 加 载 过 滤器 的 参 
数 ， 并 将 它们 的 配置 值 加 入 到 application.properties 中 ， 比 如 

Zuul.filter.root=filter 

Zuul.filter.interval=5 

其 中 ，zuul.filter.root 用 来 指定 动态 加 载 的 过 滤器 存储 路 径 ; 
zuul.filter.interval 用 来 配置 动态 加 载 的 间隔 时 间 ， 以 秒 为 单位 。 

e 创 建 用 来 加 载 自 定义 属性 的 配置 类 ， 命 名 为 FilterConfiguration， 具 
体内 容 如 下 : 

@ConfigurationProperties ("zuul.filter") 

public class FilterConfiguration { 

private String root; 

private Integer interval; 

public String getRoot () { 

return root; 


public void setRoot (String root) { 
this.root=root; 

} 

public Integer getInterval () { 
return interval; 


public void setInterval (Integer interval) { 
this.interval=interval; 


} 


} 
e 创 建 应 用 启动 主 类 ， 并 在 该 类 中 引入 上 面 定义 的 FilterConfiguration 
配置 ， 并 创建 动态 加 载 过 小 占 的 实例 。 具 体内 容 如 下 : 
(EnableZuulProxy 
@EnableConfigurationProperties ({FilterConfiguration.class}) 
SpringCloudApplication 
public class Application { 
public static void main (String[largs) { 
new 
SpringApplicationBuilder (Application.class) .web (true) .run Cargs) ; 


(Bean 

public FilterLoader filterLoader (FilterConfiguration 
filterConfiguration ) { 

FilterLoader filterLoader=FilterLoader.getInstance (); 

filterLoader.setCompiler (new GroovyCompiler () ) ; 

try { 

FilterFileManager.setFilenameFilter (new GroovyFileFilter () ) ; 

FilterFile Manager.init ( 

filterConfiguration.getInterval () ， 

filterConfiguration.getRoot () +"/pre", 

filterConfiguration.getRoot () +"/post") ; 

} catch (Exception e) { 

throw new RuntimeException (e); 

} 

return filterLoader; 


} 


} 

至 此 ， 我 们 束 已 经 完成 了 为 基础 的 API 网 关 服 务 增加 动态 加 载 过 滤器 
的 能 力 。 根 据 上 面 的 定义 ，API 网 关 应 用 会 每 隔 5 秒 ， 从 API 网 关 服 务 
所 在 位 置 的 filter/pre 和 filter/post 目 录 下 获取 Groovy 定 义 的 过 滤器， 并 对 
其 进行 编译 和 动态 加 载 使 用 。 对 于 动态 加 载 的 时 间 间 隔 ， 可 通过 
zuul.filter.interval 参 数 来 修改 。 而 加 载 过 滤 占 实现 类 的 根 目录 可 通过 
zuul.filter.root 调 整 根 目录 的 位 置 来 修改 ， 但 是 对 于 根 目 录 的 子 目 录 ， 这 
3 目录 ， 实 际 使 用 的 时 候 读 者 可 以 做 进一步 扩 

在 完成 上 述 构建 之 后 ， 我 们 可 以 将 涉及 的 服务 ， 比 如 eureka-server、 
hello-service 以 及 上 述 实 现 的 API 网 关 服 务 都 司 动 起 来 。 在 没有 加 入 任何 
自 定义 过 滤器 的 时 候 ， 根 据 路 由 规则 定义 ， 我 们 可 以 尝试 加 API 网 关 服 
务 发 起 请 求 : http:/localhost:5555/hello-service/hello， 如 果 配 置 正 确 ， 该 
请 求 会 被 API 网 关 服 务 路 由 到 hello-service 上， 并 返回 输出 Hello World。 

接 下 来 ， 我 们 可 以 在 filter/pre 和 filter/post 目 录 下 ， 用 Groovy 来 创建 一 
些 过 滤器 来 看 看 实际 效果 ， 举 例如 下 。 

e 在 filter/pre 目 录 下 创建 一 个 pre 类 型 的 过 滤器， 命名 为 
PreFilter.groovy。 

由 于 pre 类 型 的 过 滤器 在 请 求 路 由 前 执行 ， 通 常用 来 做 一 些 签名 校 验 
的 功能 ， 所 以 我 们 可 以 在 过 滤器 中 输出 一 些 请 求 相 关 的 信息 ， 比 如 下 面 














的 实现 : 

Class PreFilter extends ZuulFilter { 

Logger log=LoggerFactory.getLogger (PreFilter.class ) 

(DOverride 

String filterType () { 

return "pre" 

} 

(DOverride 

int filterOrder () { 

return 1000 

} 

(OOverride 

boolean shouldFilter () { 

return true 

} 

(DOverride 

Objectrun () { 

HttpServletRequest 
request=RequestContext.getCurrentContext () .getRequest () 

log.info ("this is a pre filter: Send {} request to {}", 

request.getMethod 〈) ， 

request.getRequestURL () .toString () ) 

return null 

} 

} 

在 加 入 了 该 过 滤器 之 后 ， 不 需要 重启 API 网 关 服 务 ， 只 需要 稍 等 几 秒 
惑 会 生效 。 我 们 可 以 继续 党 试问 API 网 关 服 务 发 起 请 求 : 
http://localhost:5555/helloservice/hello， 此 时 在 控制 台中 可 以 看 到 
PreFilter.groovy 过 滤器 中 定义 的 日 志 人 信息， 具体 如 下 : 

com.didispace.filter.pre.PreFilter : this is a pre filter: Send GET 
request to 

http://localhost:5555/ddd/hello 

e 在 filter/post 目 录 下 创建 一 个 post 类 型 的 过 滤器 ， 命 名 为 
PostFilter.groovy。 

由 于 post 类 型 的 过 小 絮 在 请 求 路 由 返回 后 执行 ， 我 们 可 以 进一步 对 
这 个 结果 做 一 些 处 理 ， 对 微服 务 返 回 的 信息 做 一 些 加 工 。 比 如 下 面 的 实 
现 : 





class PostFilter extends ZuulFilter{ 

Logger log=LoggerFactory.getLogger (PostFilter.class) 

(DOverride 

String filterType () { 

return "post" 

} 

(DOverride 

int filterOrder () { 

return 2000 

} 

(DOverride 

boolean shouldFilter () { 

return true 

} 

(DOverride 

Objectrun () { 

log.info ("this is a post filter: Receive response") 

HttpServletResponse 
response=RequestContext.getCurrentContext () .getResponse () 

response.getOutputStream () .print (",I am zhaiyongchao") 

response.flushBuffer () 

| 


} 

在 加 入 了 该 过 滤器 之 后 ， 我 们 也 不 需要 重启 API 网 关 服 务 ， 稍 等 几 秒 
后 就 可 以 符 试 同 API 网 关 服 务 发 起 请 求 : http://localhost:5555/hello- 
service/hello， 此 时 不 仅 可 以 在 控制 台中 看 到 PostFilter.groovy 过 滤器 中 
定义 的 日 志 输 出 信息 ， 也 可 以 从 请 求 返 回 的 内 容 发 现 过 滤器 的 效果 ， 该 
接口 返回 的 内 容 不 再 是 Hello World， 而 是 经 过 加 工 处 理 后 的 Hello 
World,I am zhaiyongchao。 

通过 本 节 对 动态 过 滤器 加 载 的 内 容 的 介绍 ， 可 以 看 到 ，API 网 关 服 
务 的 动态 过 滤器 功能 可 以 帮助 我 们 增强 API 网 关 的 持续 服务 能 力 ， 对 于 
网 关中 的 处 理 逻 辑 维护 也 变 得 更 为 灵活 ， 不 仪 可 以 动态 地 实现 请 求 校 
验 ， 还 可 以 动态 地 实现 对 请 求 内 容 的 干预 。 但 是 ， 目 前 版 本 下 的 动态 过 
滤器 还 是 一 个 半成品 ， 从 
org.Springframework.cloud.netflix.zuul.ZuulFilterInitializer ”的 源码 中 我 们 
也 可 以 看 到 ， 对 于 动态 过 滤器 的 加 载 是 被 注释 挤 的 ， 并 且 被 标注 了 
TODO 状态。 不过， 目前 在 实际 使 用 过 程 中 ， 对 于 处 理 一 些 简 单 的 常用 

















过 滤 功 能 还 是 没有 什么 问题 的 ， 只 是 需要 注意 一 些 已 知 的 问题 并 避 开 这 
些 情 况 来 使 用 即 可 。 比 如 ， 在 使 用 Groovy 定 义 动 态 过 滤器 的 时 候 ， 删 除 
Groovy 文 件 并 不 能 从 当前 运行 的 API 网 关中 移 除 这 个 过 滤器 ， 所 以 如 果 
要 移 除 的 话 可 以 通过 修改 Groovy 过 小 器 的 shouldFilter 返回 false。 男 外 
还 需要 注意 一 点 ， 目 前 的 动态 过 小 右 是 无 法 直接 注入 API ”网 关 服 务 的 
Spring ”容器 中 加 载 的 实例 来 使 用 的 ， 比 如 ， 我 们 是 无 法 直接 通过 注入 
RestTemplate 等 实例 ， 在 动态 过 滤器 中 对 各 个 微服 务 发 起 请 求 的 。 
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Cloud Config 


Spring Cloud Config 是 Spring Cloud 团 队 创 建 的 一 个 全 新 项 目 ， 用 来 
为 分 布 式 系统 中 的 基础 设施 和 微服 务 应 用 提供 集中 化 的 外 部 配置 文 持 ， 
它 分 为 服务 端 与 客户 端 两 个 部 分 。 其 中 服务 端 也 称 为 分 布 式 配 置 中 心 ， 
它 是 一 个 独立 的 微服 务 应 用 ， 用 来 连接 配置 仓库 并 为 客户 端 提 供 获取 配 
置信 息 、 加 密 / 解 密 信 息 等 访问 接口 ;而 客户 端 则 是 微服 务 架 构 中 的 各 
个 微服 务 应 用 或 基础 设施 ， 它 们 通过 指定 的 配置 中 心 来 管理 应 用 资源 与 
业务 相关 的 配置 内 容 ， 并 在 启动 的 时 候 从 配置 中 心 获取 和 加 载 配 置信 
轧 。Spring Cloud Config 实 现 了 对 服务 端 和 客户 端 中 环境 变量 和 属性 配 
置 的 抽象 映射 ， 所 以 它 除 了 适用 于 Spring 构建 的 应 用 程序 之 外 ， 也 可 以 
在 任何 其 他 语言 运行 的 应 用 程序 中 使 用 。 由 于 Spring Cloud Config 实 现 
的 配置 中 心 默 认 采 用 Git 来 存储 配置 信息 ， 所 以 使 用 Spring Cloud Config 
构建 的 配置 服务 器 ， 天 然 束 文 持 对 微服 务 应 用 配置 信息 的 厂 本 管理 ， 并 
且 可 以 通过 Git 客户 端 工 具 来 方便 地 管理 和 访问 配置 内 容 。 当 然 它 也 提 
供 了 对 其 他 存储 方式 的 支持 ， 比 如 SVN 仓 库 、 本 地 化 文件 系统 。 接 下 
来 ， 我 们 从 一 个 简单 的 入 门 示 例 开始 学 习 Spring Cloud Config 服 务 端 以 
及 客户 端的 详细 构建 与 使 用 方法 。 
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在 本 市 中 ， 我 们 将 演示 如 何 构 建 一 个 基于 Git 存储 的 分 布 式 配置 中 
心 ， 同 时 对 配置 的 详细 规则 进行 讲解 ， 并 在 客户 并 中 演示 如 何 通过 配置 
指定 微服 务 应 用 的 所 属 配 置 中 心 ， 并 让 其 能 够 从 配置 中 心 获取 配置 信息 
并 绑 定 到 代码 中 的 整个 过 程 。 


久 建 夕 


通过 Spring Cloud Config 构 建 一 个 分 布 式 配置 中 心 非常 简单 ， 只 需要 
以 下 三 步 。 


e 创 建 一 个 基础 的 Spring Boot 工 程 ， 命 名 为 config-server， 并 在 
pom.xml 中 引入 下 面 的 依赖 : 
<parent> 


<groupId>org.Springframework.boot</groupId> 
<artifactId>spring-boot-starter-parent</artifactId> 
<version>1.3.7.RELEASE</version> 
<relativePath/> <!--lookup parent from repository--> 
</parent> 

<dependencies> 

<dependency> 
<groupId>org.Springframework.cloud</groupId> 
<artifactId>spring-cloud-config-server</artifactId> 
</dependency> 

</dependencies> 

<dependencyManagement> 

<dependencies> 

<dependency> 
<groupId>org.Springframework.cloud</groupId> 
<artifactId>spring-cloud-dependencies</artifactId> 
<version>Brixton.SR5</version> 
<type>pom</type> 

<scope>import</scope> 

</dependency> 

</dependencies> 


</dependencyManagement> 

e 创 建 Spring Boot 的 程序 主 类 ， 并 添加 @EnableConfigServer 注 解 ， 开 
启 Spring Cloud Config 的 服务 端 功能 。 

@EnableConfigServer 

SpringBootApplication 

public class Application { 

public static void main (String[]args) { 

new 
SpringApplicationBuilder (Application.class) .web (true) .run Cargs) ; 

} 


} 

e 在 application.properties 中 添加 配置 服务 的 基本 信息 以 及 Git 仓 库 的 相 
关 信 息 ， 如 下 所 示 : 

spring.application.name=config-server 

server.port=7001 

spring.cloud.config.server.git.uri=http://git.oschina.net/didispace/SpringC] 
Learning/ 

spring.cloud.config.server.git.searchPaths=spring_cloud_in_action/config: 
repo 

spring.cloud.config.server.git.username=username 

spring.cloud.config.server.git.password=password 

其 中 Git 的 配置 信息 分 别 表示 如 下 内 容 。 

espring.cloud.config.server.git.uri: 配置 Git 仓 库 位 置 。 

espring.cloud.config.server.git.searchPaths: 配置 仓库 路 径 下 的 相对 搜 
索 位 置 ， 可 以 配置 多 个 。 

espring.cloud.config.server.gitusername: 访问 Git 仓 库 的 用 户 名 。 

espring.cloud.config.server.git.password: 访问 Git 仓 库 的 用 户 密码 。 

到 这 里 ， 使 用 一 个 通过 Spring Cloud Config 实 现 ， 并 使 用 Git 管 理 配 置 
内 容 的 分 布 式 配 置 中 心 就 完成 了 。 我 们 可 以 将 该 应 用 先 局 动 起 来 ， 确 保 
没有 错误 产生 ， 然 后 进入 下 面 的 学 习 内 容 。 


配置 规则 详解 


为 了 验证 上 面 完 成 的 分 布 式 配置 中 心 config-server， 根 据 Git 配置 信 
息 中 指定 的 仓库 位 置 ， 在 http://git.oschina.net/didispace/SpringCloud- 
Learning/spring_cloud_in_action/ 下 创建 了 一 个 config-repo 目录 作为 配置 
仓库 ， 并 根据 不 同 环 境 新 建 下 面 4 个 配置 文件 : 











edidispace.properties 

edidispace-dev.properties 

edidispace-test.properties 

edidispace-prod.properties 

在 这 4 个 配置 文件 中 均 设置 了 一 个 from 属 性 ， 并 为 每 个 配置 文件 分 别 
设置 了 不 同 的 值 ， 如 下 所 示 : 

efrom=git-default-1.0 

efrom=git-dev-1.0 

efrom=git-test-1.0 

efrom=git-prod-1.0 

为 了 测试 版 本 控制 ， 在 该 Git 仓 库 的 master 分 文中 ， 我 们 为 from 属 性 
加 入 1.0 的 后 级 ， 同 时 创建 一 个 config-label-test 分 支 ， 并 将 各 配置 文件 中 
的 值 用 2.0 作 为 后 级 。 

完成 了 这 些 准 备 工作 之 后 ， 我 们 就 可 以 通过 浏览 器 、POSTMAN 或 
CURL 等 工具 直接 来 访问 我 们 的 配置 内 容 了 。 访 问 配置 信息 的 URL 与 配 
置 文件 的 映射 关系 如 下 所 示 : 

e/{application}/{profile}[/{label}] 

e/{application}-{profile}.yml 

e/{label}/{application}-{profile}.yml 

e/{application}-{profile}.properties 

e/{label}/{application}-{profile}.properties 

上 面 的 rl 会 映射 {application}-{profile}.properties 对 应 的 配置 文件 ， 
其 中 {label} 对 应 Git 上 不 同 的 分 支 ， 默 认为 master。 我 们 可 以 尝试 构造 不 
同 的 un 来 访问 不 同 的 配置 内 容 ， 比 如 ， 要 访问 config-label-test 分 支 ， 
didispace 应 用 的 prod 环 境 ， 就 可 以 访问 这 个 
url:http://localhost:7001/didispace/prod/configlabel-test， 并 获得 如 下 返回 


[WD 











"name": "didispace", 
"profiles":[ 
"prod" 


"label": "config-label-test", 
"version": "4c4f3909b0499b8518abalf76e8a90b0dbad535d", 
"propertySources":[ 


{ 
"name": "http://git.oschina.net/didispace/SpringCloud- 


Learning/spring_cloud_in_action/config-repo/didispace-prod.properties"， 


"source": { 

"from": "git-prod-2.0" 

} 

上 

{ 

"name": "http://git.oschina.net/didispace/SpringCloud- 
Learning/spring_cloud_ in_ action/config-repo/didispace.properties", 

"source": { 

"from": "git-default-2.0" 

} 

} 

] 


} 

我 们 可 以 看 到 该 JSON 中 返回 了 应 用 名 didispace， 环 境 名 prod， 分 文 
名 config-label-test， 以 及 default 环 境 和 prod 环 境 的 配置 内 容 。 另 外 ， 之 前 
没有 提 到 过 的 version， 从 下 图 我 们 可 以 观察 到 ， 它 对 应 的 是 在 Git 上 的 


commit 号 。 


同时 ， 我 们 可 以 看 到 config-server 的 控制 台中 还 输出 了 下 面 的 内 容 ， 
配置 服务 器 在 从 Git 中 获取 配置 信息 后 ， 会 存储 一 份 在 config-server 的 
文件 系统 中 ， 实 质 上 config-server 是 通过 git clone 命 令 将 配置 内 容 复制 了 
一 份 在 本 地 存储 ， 然 后 读 取 这 些 内 容 并 返回 给 微服 务 应 用 进行 加 载 。 
s.C.a.AnnotationConfigApplicationContext : Refreshing 
org.Springframework.context.annotation.AnnotationConfigApplicationCol 
startup date[Fri Sep 16 21:56:43 CST 2016]; root of context hierarchy 
0.$.C.C.S.e.NativeEnvironmentRepository : Adding property source: 
file:/C:/Users/ADMINI~1/AppData/Local/Temp/config-repo- 
914347082723810766/spring_dl 
oud_in_action/config-repo/didispace-prod.properties 
0.$.C.C.S.e.NativeEnvironmentRepository : Adding property source: 
file:/C:/Users/ADMINI~1/AppData/Local/Temp/config-repo- 
914347082723810766/Spring_cl 
oud_in_action/config-repo/didispace.Properties 
s.c.a.AnnotationConfigApplicationContext : Closing 
org.Springframework.context.annotation.AnnotationConfigApplicationCol 
startup date[Fri Sep 16 21:56:43 CST 2016]; root of context hierarchy 














config-server 通 过 Git 在 本 地 仓库 暂 存 ， 可 以 有 效 防止 当 Git 仓 库 出 现 
故障 而 引起 无 法 加 载 配置 信息 的 情况 。 我 们 可 以 通过 断 开 网 络 ， 再 次 发 
起 http://localhost:7001/didispace/prod/config-label-test 请 求 ， 在 控制 台中 
可 输出 如 下 妆容 。 可 以 看 到 ，config-server 提 示 无 法 从 远程 获取 该 分 支 
内 容 的 报错 信息 : Could not pull remote for config-label-test， 但 是 它 依 然 
会 为 该 请 求 返 回 配置 内 容 ， 这 些 内 容 源 于 之 前 访问 时 存 于 config-server 
本 地 文件 系统 中 的 配置 内 容 。 

.C.S.e.MultipleJGitEnvironmentRepository : Could not pull remote for 
config-label-test 

(current ref=Ref[refs/heads/config-label-test= 
4c4f3909b0499b8518abalf76e8a90b0dbad535d]) ,remote: 
http://git.oschina.net/didispace/SpringCloud-Learning 
s.c.a.AnnotationConfigApplicationContext : Refreshing 
org.springframework.context.annotation. AnnotationConfigApplicationCoi 
startup date[Mon Sep 19 10:51:04 CST 2016]; root of context hierarchy 
0.S.C.C.S.e.NativeEnvironmentRepository : Adding property source: 
file:/C:/Users/ADMINI~1/AppData/Local/Temp/config-repo- 

7514536618307405051/spring_c 
loud_in_action/config-repo/didispace-prod.properties 
0.S.C.C.S.e.NativeEnvironmentRepository : Adding property source: 
file:/C:/Users/ADMINI~1/AppData/Local/Temp/config-repo- 

7514536618307405051/spring_c 
loud_in_action/config-repo/didispace.properties 
s.c.a.AnnotationConfigApplicationContext : Closing 
org.Springframework.context.annotation.AnnotationConfigApplicationCol 
startup date[Mon Sep 19 10:51:04 CST 2016]; root of context hierarchy 





» 让 日 - 


在 完成 了 上 述 验 证 之 后 ， 确 定 配 置 服务 中 心 已 经 正常 运作 ， 下 面 我 
们 尝试 如 何在 微服 务 应 用 中 获取 上 述 配 置信 息 。 

e 创 建 一 个 Spring Boot 应 用 ， 命 名 为 config-client， 并 在 pom.xml 中 引 
入 下 述 依赖 : 

<parent> 

<groupId>org.Springframework.boot</groupId> 

<artifactId>spring-boot-starter-parent</artifactId> 

<version>1.3.7.RELEASE</version> 


<relativePath/> <!--lookup parent from repository--> 
</parent> 
<dependencies> 
<dependency> 
<groupId>org.Springframework.boot</groupId> 
<artifactId>spring-boot-starter-web</artifactId> 
</dependency> 
<dependency> 
<groupId>org.Springframework.cloud</groupId> 
<artifactId>spring-cloud-starter-config</artifactId> 
</dependency> 
</dependencies> 
<dependencyManagement> 
<dependencies> 
<dependency> 
<groupId>org.Springframework.cloud</groupId> 
<artifactId>spring-cloud-dependencies</artifactId> 
<version>Brixton.SR5</version> 
<type>pom</type> 
<scope>import</scope> 
</dependency> 
</dependencies> 
</dependencyManagement> 
e 创 建 Spring Boot 的 应 用 主 类 ， 具 体 如 下 : 
SpringBootApplication 
public class Application { 
public static void main (String[]args) { 
new 

SpringApplicationBuilder (Application.class) .web (true) .run (args); 


} 

e 创 建 bootstrap.properties 配置 ， 来 指定 获取 配置 文件 的 config-server 
位 置 ， 例 如 : 

spring.application.name=didispace 

spring.cloud.config.profile=dev 

spring.cloud.config.label=master 

spring.cloud.config.uri=http://localhost:7001/ 


server.port=7002 


上 述 配 置 参数 与 Git 中 存储 的 配置 文件 中 各 个 部 分 的 对 应 关系 如 下 所 


espring.application.name: 对 应 配置 文件 规则 中 的 ee 六 这 

espring.cloud.config.profile: 对 应 配置 文件 规则 中 的 {profile} 部 分 

espring.cloud.config.label: 对 应 配置 文件 规则 中 的 {label} 部 分 。 

espring.cloud.config.uri: 配置 中 心 config-server 的 地 址 。 

这 里 需要 格外 注意 ， 上 面 这 些 属性 必须 配置 在 。 bootstrap.properties 
中 ， 这 样 config-server 中 的 配置 信息 才能 被 正确 加 载 。 在 第 2 章 中 ， 我 们 
详细 说 明了 Spring Boot 对 配置 文件 的 加 载 顺序 ， 对 于 本 应 用 jar 包 之 外 的 
配置 文件 加 载 会 优先 于 应 用 jar 包 内 的 配置 内 容 ， 而 通过 
bootstrap.properties 对 config-server 的 配置 ， 使 得 该 应 用 会 从 config-server 
中 获取 一 些 外 部 配置 信息 ， 这 些 信息 的 优先 级 比 本 地 的 内 容 要 高 ， 从 而 
实现 了 外 部 化 配置 。 

e 创 建 一 个 RESTful 接 口 来 返回 配置 中 心 的 from 属 性 ， 
@Value ("${from}")〉 绑 定 配 置 服务 中 配置 的 from 属 性 ， 具 i 如 

@RefreshScope 

(DRestController 

public class TestController { 

@Value ("${from}") 

private String from; 

@RequestMapping ("/from") 

public String from () { 

return this.from:; 


} 


} 

e 除 了 通过 @Value 注 解 绑 定 注入 之 外 ， 也 可 以 通过 Environment 对 象 
来 获取 配置 属性 ， 比 如 : 

@RefreshScope 

(DRestController 

public class TestController { 

(OAutowired 

private Environment enyv; 

@RequestMapping ("/from") 

public String from () { 

return env.getProperty ("from","undefined") ; 








} 


} 

启动 config-dlient 应 用 ， 并 访问 http://localhost:7002/from， 我 们 就 可 以 
根据 配置 内 容 输 出 对 应 环境 的 from 内 容 了 。 根 据 当 前 配置 ， 我 们 可 以 获 
得 如 下 返回 内 容 git-dev-1.0。 可 以 继续 通过 修改 bootstrap.properties 中 
的 配置 内 容 获取 不 同 的 配置 信息 来 熟悉 配置 服务 中 的 配置 规则 。 


在 上 一 节 中 ， 我 们 实现 了 一 个 具备 基本 结构 的 配置 管理 服务 端 和 客 
户 端 ， 同 时 讲解 了 其 中 一 些 配 置 的 基本 原理 和 规则 。 在 本 节 中 ， 我 们 将 
进一步 介绍 Spring Cloud Config 服 务 端的 一 些 相 关 知 识 和 用 法 。 


基础 架构 


在 动手 实践 了 上 面 关 于 Spring Cloud Config 的 基础 入 门 内 容 之 后 ， 在 
这 里 我 们 深入 理解 一 下 它 是 如 何 运作 起 来 的 。 下 图 所 示 的 是 上 一 市 我 们 
所 构建 案例 的 基本 结构 。 

其 中 ， 主 要 包含 下 面 几 个 要 素 。 

e 远 程 Git 仓库 : 用 来 存储 配置 文件 的 地 方 ， 上 例 中 我 们 用 来 存储 针 
对 应 用 名 为 didispace 的 多 环境 配置 文件 : didispace-{profile}.properties。 

eConfig Server: 这 是 我 们 上 面 构建 的 分 布 式 配置 中 心 ，config-server 
Te 密码 等 连 

e 本 地 Git 仓 库 : 在 Config Server 的 文件 系统 中 ， 每 次 客户 端 请 求 获取 
配置 信息 时 ，Config Server 从 Git 仓 库 中 获取 最 新 配置 到 本 地 ， 然 后 在 本 
地 Git 仓 库 中 读 取 并 返回 。 

当 远 程 仓 库 无 法 获取 时 ， 直 接 将 本 地 内 容 返 回 。 

eService A、Service B: 具体 的 微服 务 应 用 ， 它 们 指定 了 Config 
Server 的 地 址 ， 从 而 实现 从 外 部 化 获取 应 用 自己 要 用 的 配置 信息 。 这 些 
应 用 在 启动 的 时 候 ， 会 向 Config Server 请 求 获取 配置 信息 来 进行 加 载 。 


客户 端 应 用 从 配置 管理 中 获取 配置 信息 遵从 下 面 的 执行 流程 : 

1. 应 用 启动 时 ， 根 据 bootstrap.properties 中 配置 的 应 用 名 
{application}、 环 境 名 {profile}、 分 支 名 {label}， 癌 Config Server 请 求 获 
取 配 置信 息 。 

2.Config Server 根 据 上 自己 维护 的 Git 仓 库 信息 和 客户 并 传递 过 来 的 配置 
定位 信息 去 查找 配置 信息 。 

3. 通 过 git clone 命 令 将 找到 的 配置 信息 下 载 到 Config Server 的 文件 系 
Hs 

4.Config Server 创 建 Spring 的 ApplicationContext 实 例 ， 并 从 Git 本 地 仓 
库 中 加 载 配置 文件 ， 最 后 将 这 些 配置 内 容 读 取 出 来 返回 给 客户 端 应 用 。 

5. 客 户 端 应 用 在 获得 外 部 配置 文件 后 加 载 到 客户 端的 





























ApplicationContext 实 例 ， 访 配置 内 容 的 优先 级 高 于 客户 端 Jar 包 内 部 的 配 
置 内 容 ， 所 以 在 Jar 包 中 重复 的 内 容 将 不 再 被 加 载 。 

Config Server 巧 妙 地 通过 git clone 将 配置 信息 存 于 本 地 ， 起 到 了 绥 存 
的 作用 ， 即 使 当 Git 服 务 端 无 法 访问 的 时 候 ， 依然 可 以 取 Config Server 中 
的 缓存 内 容 进行 使 用 。 


Git 配 置 仓库 


在 Spring Cloud Config 的 服务 端 ， 对 于 配置 仓库 的 默认 实现 采用 了 
Git。Git 非 常 适用 于 存储 配置 内 容 ， 它 可 以 非常 方便 地 使 用 各 种 第 三 方 
工具 来 对 其 内 容 进 行 管理 更 新 和 版 本 化 ， 同 时 Git 仓 库 的 Hook 功 能 还 可 
以 帮助 我 们 实时 地 监控 配置 内 容 的 修改 。 其 中 ，Git 目 喘 的 版 本 控制 功 
能 正 是 其 他 一 些 配 置 中 心 所 欠缺 的 ， 通 过 Git 进行 存储 意味 着 ， 一 个 应 
用 的 不 同 部 壮实 例 可 以 从 Spring Cloud Config 的 服务 端 获 取 不 同 的 版 本 
配置 ， 从 而 文 持 一 些 特 殊 的 应 用 场景 。 

Spring Cloud Config 中 默认 使 用 Git， 所 以 对 于 Git 的 配置 也 非常 
简单 ， 只 需 在 Config Server 的 application.properties 中 设置 
spring.cloud.config.server.git.uri 属 性 ， 为 其 指定 Git 仓 库 的 网 络 地 址 和 账 
户 信 息 即 可 ， 比 如 在 快速 入 门 一 市 中 的 例子 : 

spring.cloud.config.server.git.uri=http://git.oschina.net/didispace/SpringC] 
Learning/ 

spring.cloud.config.server.git.username=username 

spring.cloud.config.server.git.password=password 

如 果 我 们 将 该 值 通 过 file:// 前 级 来 设置 为 一 个 文件 地 址 (在 Windows 
系统 中 ， 需 要 使 用 file:// 来 定位 文件 内 容 ) ， 那 么 它 将 以 本 地 仓库 的 方 
> 这 样 我 们 就 可 以 脱离 Git 服 务 端 来 快速 进行 调试 与 开发 ， 比 

0: 

spring.cloud.config.server.git.uri=file://$ {user.home}/config-repo 

其 中 ，S${user.home} 代 表 当 前 用 户 的 所 属 目录 。file:// 配 置 的 本 地 文 
件 系统 方式 虽然 对 于 本 地 开发 调试 时 使 用 非常 方便 ， 但 是 该 方式 也 仅 用 
于 开发 与 测试 ， 在 生产 环境 中 请 务必 搭建 自己 的 Git 仓 库 来 存储 配置 资 

占 位 符 配 置 URI 

{application}、{profile}、{label} 这 些 占 位 符 除 了 用 于 标识 配置 文件 
的 规则 之 外 ， 还 可 以 用 于 Config Server 中 对 Git 仓库 地 址 的 URI 配置 。 
比如 ， 我 们 可 以 通过 {application} 占 位 符 来 实现 一 个 应 用 对 应 一 个 Git 仓 
库 日 录 的 配置 效果 ， 具 体 配置 实现 如 下 : 

















spring.cloud.config.server.git.uri=http://git.oschina.net/didispace/{applicat 

spring.cloud.config.server.git.username=username 

spring.cloud.config.server.git.password=password 

其 中 ，{application} 代 表 了 应 用 名 ， 所 以 当 客 户 端 应 用 向 Config 
Server 发 起 获取 配置 的 请 求 时 ，Config Server 会 根据 客户 端的 
spring.application.name 信 息 来 填充 {application} 占 位 符 以 定位 配置 资源 的 
存储 位 置 ， 从 而 实现 根据 微服 务 应 用 的 属性 动态 获取 不 同位 置 的 配置 。 
另外 ， 在 这 些 占 位 符 中 ，{label} 参 数 较为 特别 ， 如 果 Git 的 分 文 和 标签 名 
包含 “”， 那 么 {label} 参 数 在 HITP 的 URL 中 应 该 使 用 * 〈_) ”来 替代 ， 以 
避免 改变 了 URI 含 义 ， 指 向 到 其 他 的 URI 资 源 。 

当 我 们 使 用 Git 作为 配置 中 心 来 存储 各 个 微服 务 应 用 配置 文件 的 时 
候 ， 该 功能 会 变 得 非常 有 用 ， 通 过 在 URI 中 使 用 占 位 符 可 以 帮助 我 们 规 
划 和 实现 通用 的 仓库 配置 。 例 如 ， 我 们 可 以 对 微服 务 应 用 做 如 下 规划 。 

e 代 人 码 库 : ”使 用 服务 名 作为 Git 仓库 名 称 ， 比 如 会 员 服 务 的 代码 库 
http://git.oschina.net/didispace/member-service。 

e 配 置 库 : ”使 用 服务 名 加 上 -config 后 级 作为 Git 仓 库 名 称 ， 比 如 上 而 
会 员 服 务 对 应 的 配置 库 地 址 位 置 http://git.oschina.net/didispace/member- 
Serviceconfig 。 

这 时 ， 我 们 就 可 以 使 用 
spring.cloud.config.server.git.uri=http://git.oschina.net/didispace/{application 
config 配置 ， 来 同时 匹配 多 个 不 同 服务 的 配置 仓库 。 

配置 多 个 仓库 

Config ”Server 除 了 可 以 通过 application 和 profile 模 式 来 匹配 配置 仓库 
之 外 ， 还 文 持 通过 带 有 通配符 的 表达 式 来 匹配 ， 以 实现 更 为 复杂 的 配置 
需求 。 并 且 当 我 们 有 多 个 匹配 规则 的 时 候 ， 还 可 以 用 逗号 来 分 割 多 个 
{application}/{profile} 配 置 规则 ， 比 如 : 

spring.cloud.config.server.git.uri=http://git.oschina.net/didispace/config- 
repo 

spring.cloud.config.server.git.repos.dev.pattern=dev/* 

spring.cloud.config.server.git.repos.dev.uri=file://home/git/config-repo 

spring.cloud.config.server.git.repos.test=http://git.oschina.net/test/config- 
repo 

spring.cloud.config.server.git.repos.prod.pattern=prod/pp*,online/oo* 

spring.cloud.config.server.git.repos.prod.uri=http://git.oschina.net/prod/co 
g-repo 

上 述 配 置 内 容 通 过 spring.cloud.config.server.git.uri 属性 ， 指 定 了 一 个 
默认 的 仓库 位 置 ， 当 使 用 {application}/{profile} 模 式 未 能 匹配 到 合适 的 

















仓库 时 ， 就 将 在 该 默认 仓库 位 置 下 获取 配置 信息 。 除 此 之 外 ， 还 配置 了 
三 个 仓库 ， 分 别 是 dev、test、prod。 其 中 ，dev 仓库 匹配 dev/* 的 模式 ， 
所 以 无 论 profile 是 什么 ， 它 都 能 匹配 application 名 称 为 dev 的 应 用 。 并 且 
我 们 可 以 注意 到 ， 它 存储 的 配置 文件 位 置 还 采用 了 Config Server 的 本 地 
文件 系统 中 的 内 容 。 对 于 此 配置 ， 我 们 可 以 通过 访问 
http://localhost:7001/dev/profile 的 请 求 来 验证 到 该 仓库 的 配置 内 容 ， 其 中 
profile 可 以 为 任意 值 。 而 test 和 prod 仓 库 均 使 用 了 Git 仓 库 的 存储 ， 并 且 
test 仓 库 未 配置 匹配 规则 ， 所 以 它 只 匹配 application 名 为 test 的 应 用 :prod 
仓库 则 需要 匹配 application 为 prod 并 且 profile 为 pp 开头 ， 或 者 application 
为 online 并 且 profile 为 oo 开头 的 应 用 和 环境 。 

当 配 置 多 个 仓库 的 时 候 ，Config Server 在 启动 时 会 直接 克隆 第 一 个 仓 
库 的 配置 库 ， 其 他 的 配置 库 只 有 在 请 求 时 才 会 克隆 到 本 地 ， 所 以 对 于 仓 
库 的 排列 可 以 根据 配置 内 容 的 重要 程度 有 所 区 分 。 另 外 ， 如 果 表 达 式 是 
以 通配符 开始 的 ， 那 么 需要 使 用 引号 将 配置 内 容 引 起 来 。 

子 目录 存储 

除了 文 持 占 位 符 配 置 、 多 仓库 配置 之 外 ，Config Server 还 可 以 将 配 
置 文件 定位 到 ”Git 仓库 的 子 目录 中 。 有 心 的 读者 ， 或 许 还 能 记得 在 快速 
入 门 中 ， 我 们 除了 配置 spring.cloud.config.server.git.uri ”属性 之 外 ， 还 配 
置 了 另外 一 个 参数 : spring.cloud.config.server.git.searchPaths， 通 过 该 参 
数 我 们 实现 了 在 http://git.oschina.net/didispace/SpringCloud-Learning/ 仓 库 
的 spring_cloud_in_action/config-repo 子 目录 下 实现 配置 的 存储 。 

对 于 spring.cloud.config.server.git.searchPaths 参数 的 配置 也 支持 使 用 
{application}、 {profile} 和 {label} 占 位 符 ， 比 如 : 

spring.cloud.config.server.git.uri=http://git.oschina.net/didispace/SpringC!] 
Learning/ 

spring.cloud.config.server.git.searchPaths={application} 

通过 上 面 的 配置 ， 我 们 可 以 实现 在 
http://git.oschina.net/didispace/SpringCloud-Learning/ 仓 库 中 ， 一 个 应 用 一 
个 目录 的 效果 。 

访问 权限 

Config Server 在 访问 Git 仓 库 的 时 候 ， 知 采用 HITP 的 方式 进行 认证 ， 
那么 我 们 需要 增加 usemame 和 password 属 性 来 配置 账户 (快速 入 门 中 也 
是 如 此 实现 ) ， 比 如 : 

spring.cloud.config.server.git.uri=http://git.oschina.net/didispace/applicati 

spring.cloud.config.server.git.username=username 

spring.cloud.config.server.git.password=password 


若 不 使 用 HTTP 的 认证 方式 ， 我 们 也 可 采用 SSH 的 方式 ， 通 过 生成 




















Key 并 在 Git 仓 库 中 进行 配置 匹配 以 实现 访问 。 
SVN 配 置 仓库 


Config ”Server 除 了 支持 Git 仓 库 之 外 ， 也 能 使 用 SVN 仓 库 ， 只 需要 做 
如 下 配置 。 

e 在 pom.xml 中 引入 SVN 的 依赖 配置 ， 让 Config Server 拥 有 读 取 SVN 
内 容 的 能 

<dependency> 

<groupId>org.tmatesoft.sSvVnkit</groupId> 

<artifactId>svnkit</artifactId> 

<version>1.8.10</version> 

</dependency> 

e 在 application.properties 中 使 用 SVN 的 配置 属性 来 指定 SVN 服 务 器 的 
位 置 ， 以 及 访问 的 账 尸 名 与 密码 : 

spring.cloud.config.server.svn.uri=svn://localhost:443/didispace/config- 
repo 

spring.cloud.config.server.svn.username=username 

spring.cloud.config.server.svn.password=password 

通过 上 面 的 配置 修改 ，Config Server 就 可 以 使 用 SVN 作 为 仓库 来 存储 
jh 了 ， 而 对 于 客户 病 来 说 ， 这 个 过 程 是 透明 的 ， 所 以 不 需要 做 任 
何 变 动 。 


本 地 仓库 


在 使 用 了 Git 或 SVN 仓 库 之 后 ， 文 件 都 会 在 Config ”Server 的 本 地 文件 
系统 中 存储 一 份 ， 这 些 文件 默认 会 被 存储 于 以 config-repo 为 前 级 的 临时 
目录 中 ， 比 如 名 为 /tmp/config-repo-< 随 机 数 > 的 目录 。 由 于 其 随机 性 以 
及 临时 目录 的 特性 ， 可 能 会 有 一 些 不 可 预知 的 后 果 ， 为 了 避免 将 来 可 能 
会 出 现 的 问题 ， 最 好 的 办 法 就 是 指定 一 个 固定 的 位 置 来 存储 这 些 重 要 信 
晨 。 我 们 只 需要 通过 spring.cloud.config.server.git.basedir 或 
spring.cloud.config.server.svn.basedir 来 配置 一 个 我 们 准备 好 的 目录 即 
可 。 














地 2 


Spring Cloud Config 也 提供 了 一 种 不 使 用 Git 仓 库 或 SVN 仓 库 的 存储 方 








式 ， 而 是 使 用 本 地 文件 系统 的 存储 方式 来 保存 配置 信息 。 实 现 方式 也 非 
常 简单 ， 我 们 只 需要 设置 属性 spring.profiles.active=native,Config Server 
会 默认 从 应 用 的 src/main/resource 目录 下 搜索 配置 文件 。 如 果 需 要 指定 
搜索 配置 文件 的 路 径 ， 我 们 可 以 通过 
spring.cloud.config.server.native.searchLocations 属性 来 指定 具体 的 配置 文 
件 位 置 。 

虽然 Spring Cloud Config 提 供 了 这 样 的 功能 ， 但 是 为 了 文 持 更 好 的 内 
容 管理 和 版 本 控制 等 强大 功能 ， 还 是 推荐 使 用 Git 仓 库 的 方式 。 


健康 监测 


当 使 用 占 位 符 来 配置 URI 的 时 候 ， 很 有 可 能 在 控制 台中 出 现 类 似 这 
样 的 警告 信息 《以 
spring.cloud.config.server.git.uri=http://git.oschina.net/didispace/{application 
config 配 置 为 例 ) : 

0.S.C.C.S.e.JGitEnvironmentRepository : Could not fetch remote for 
master remote: 

http://git.oschina.net/didispace/app-config 

而 引起 该 警告 的 原因 是 由 于 Spring Cloud Config 的 服务 端 为 spring- 
bootactuator 模块 的 /health 端点 实现 了 对 应 的 健康 检测 器 : 
org.springframework.cloud.config.server.config.ConfigServerHealthIndicator 
在 该 检测 嚣 中， 默认 构建 了 一 个 application 为 app 的 仓库 。 而 根据 之 前 的 
配置 规则 : {application}config.git， 该 检测 器 会 不 断 地 检查 
http://git.oschina.net/didispace/app-config 仓库 是 否 可 以 连通 。 此 时 ， 我 们 
可 以 访问 配置 中 心 的 /health 端点 来 查看 它 的 健康 状态 ， 具 体 返 回信 息 如 
下 : 

















"configServer": { 

"status": "DOWN,", 

"repository": { 

"application": "app", 

"profiles": "default" 

}, 

"error": 
"org.springframework.cloud.config.server.environment.NoSuchLabelExceptic 
such label: master" 

} 

从 /health 端点 的 返回 信息 中 ， 我 们 可 以 看 到 ， 由 于 无 法 连通 


http:/git.oschina.net/didispace/app-config 人 仓库， 使 得 配置 中 心 的 可 用 状态 
是 DOWN。 虽 然 我 们 依然 可 以 通过 URI 的 方式 访问 该 配置 中 心 ， 但 是 当 
将 配置 中 心服 务 化 使 用 的 时 候 ， 该 状态 将 影响 它 的 服务 可 用 性 判断 。 所 
我 们 需要 了 解 它 的 健康 检测 配置 ， 并 让 它 的 健康 检测 器 正常 工作 起 


根据 默认 配置 规则 ， 我 们 可 以 直接 在 Git 仓 库 中 创建 一 个 名 为 app- 
config 的 配置 库 ， 让 健康 检测 器 能 够 访问 到 它 。 男 外 ， 也 可 以 配置 一 个 
实际 存在 的 仓库 来 进行 连通 检测 ， 比 如 下 面 的 配置 ， 它 实现 了 通过 连接 
check-repo-config 仓 库 来 进行 健康 监测 : 

spring.cloud.config.server.git.uri=http://git.oschina.net/didispace/{applicar 
n}-config 

spring.cloud.config.server.git.username=username 

spring.cloud.config.server.git.username=password 

Spring.cloud.config.server.health.repositories.check.name=check-repo 

Spring.cloud.config.server.health.repositories.check.label=master 

Spring.cloud.config.server.health.repositories.check.profiles=default 

由 于 健康 检测 的 repositories 是 个 Map 对 象 ， 所 以 实际 使 用 时 我 们 可 以 
配置 多 个 。 而 每 个 配置 中 包含 了 与 定位 仓库 地 址 时 类 似 的 三 个 元 素 。 

ename: 应 用 名 。 

elabel: 分 文 名 。 

eprofiles: 环境 名 。 

如 果 我 们 不 想 使 用 该 健康 检测 器 ， 也 可 以 通过 使 用 
spring.cloud.config.server.health.enabled=false 参 数 设置 来 关闭 它 。 


属 性 轿 2 


Config Server 还 有 一 个 “属性 履 羡 ?” 的 特性 ， 它 可 以 让 开发 人 员 为 所 有 
的 应 用 提供 配置 属性 ， 只 需要 通过 spring.cloud.config.server.overrides 属 
1 这 些 参数 会 以 Map 的 方式 加 载 到 客户 端的 配置 

。 比 如 : 

spring.cloud.config.server.overrides.name=didi 

spring.cloud.config.server.overrides.from=shanghai 

通过 该 属性 配置 的 参数 ， 不 会 被 Spring “Cloud 的 客户 端 修改 ， 并 且 
Spring Cloud 客 户 端 从 Config Server 中 获取 配置 信息 时 ， 都 会 取得 这 些 配 
置信 息 。 利 用 该 特性 可 以 方便 地 为 Spring “Cloud 应 用 配置 一 些 共同 属性 
或 是 默认 属性 。 当 然 ， 这 些 属性 并 非 强 制 的 ， 我 们 可 以 通过 改变 客户 端 
中 更 高 优先 级 的 配置 方式 〈 比 如， 配置 环境 变量 或 是 系统 属性 ) ， 来 选 


择 是 否 使 用 Config Server 提 供 的 默认 值 。 


由 于 配置 中 心 存储 的 内 容 比 较 敏感 ， 做 一 定 的 安全 处 理 是 必需 的 。 
为 配置 中 心 实 现 安全 保护 的 方式 有 很 多 ， 比 如 物理 网 络 限制 、OAuth2 
授权 等 。 不 过 ， 由 于 我 们 的 微服 务 应 用 和 配置 中 心 都 构建 于 Spring Boot 
基础 上 ， 所 以 与 Spring Security 结 合 使 用 会 更 加 方便 。 

我 们 只 需要 在 配置 中 心 的 pom.xml 中 加 入 spring-boot-starter-security 依 
赖 ， 不 需要 做 任何 其 他 改动 就 能 实现 对 配置 中 心 访问 的 安全 保护 。 

<dependency> 

<groupId>org.Springframework.boot</groupId> 

<artifactId>spring-boot-starter-security</artifactId> 

</dependency> 

默认 情况 下 ， 我 们 可 以 获得 一 个 名 为 user ”的 有 用户， 并且 在 配置 中 心 
启动 的 时 候 ， 在 日 志 中 打印 出 该 用 户 的 随机 密码 ， 有 具体 如 下 : 

INFO 22028---[ 
mainjb.a.s.AuthenticationManagerConfiguration : Using 

default security password: 1a32a848-da0c-4590-9c58-e860be8c50dd 

大 多 数 情 况 下 ， 我 们 并 不 会 使 用 随机 生成 密码 的 机 制 。 我 们 可 以 在 
配置 文件 中 指定 用 户 和 和 密码， 比如 : 

security.user.name=user 

security.user.password=37cc5635-559b-4e6f-b633-7e932b813f73 

由 于 我 们 已 经 为 config-server 设 置 了 安全 保护 ， 如 果 这 时 候 连 接 到 配 
置 中 心 的 客户 端 中 没有 设置 对 应 的 安全 信息 ， 在 获取 配置 信息 时 会 返回 
401 错 误 。 所 以 ， 需 要 通过 配置 的 方式 在 客户 端 中 加 入 安全 信息 来 通过 
校 验 ， 比 如 : 

spring.cloud.config.username=user 

Spring.cloud.config.password=37cc5635-559b-4e6f-b633-7e932b813f73 











2 作 由 22 


在 微服 务 架构 中 ， 我 们 通常 会 采用 DevOps 的 组 织 方式 来 降低 因 团 
队 间 沟通 造成 的 巨大 成 本 ， 以 加 速 微服 务 应 用 的 交付 能 力 。 这 束 使 得 原 
本 由 运 维 团队 控制 的 线 上 信息 将 交 由 微服 务 所 属 组 织 的 成 员 目 行 维护 ， 
其 中 将 会 包括 大 量 的 敏感 信息 ， 比 如 数据 库 的 账户 与 密码 等 。 显 然 ， 如 
果 我 们 直接 将 敏感 信息 以 明文 的 方式 存储 于 微服 务 应 用 的 配置 文件 中 古 





非常 危险 的 。 针 对 这 个 问题 ，Spring Cloud Config 提 供 了 对 属性 进行 加 
密 解 密 的 功能 ， 以 保护 配置 文件 中 的 信息 安全 。 比 如 下 面 的 例子 : 

spring.datasource.username=didi 

spring.datasource.password= 
{cipher}dba6505baa81d78bd08799d8d4429de499bd4c2053c0 
5f029e7cfbf143695f5b 

在 Spring Cloud Config 中 通过 在 属性 值 前 使 用 {cipher} 前 级 来 标注 该 
内 容 是 一 个 加 密 值 ， 当 微服 务 客户 端 加 载 配 置 时 ， 配 置 中 心 会 自动 为 种 
有 {cipher} 前 级 的 值 进行 解密 。 通 过 该 机 制 的 实现 ， 运 维 团 队 就 可 以 放 
心地 将 线 上 信息 的 加 密 资 源 给 到 微服 务 团 队 ， 而 不 用 担心 这 些 敏感 信息 
1 下 面 我 们 来 具体 介绍 如 何在 配置 中 心 使 用 该 项 功能 。 

HY $e 

在 使 用 Spring Cloud Config 的 加 和 密 解密 功能 时 ， 有 一 个 必要 的 前 提 需 
要 我 们 注意 。 为 了 局 用 该 功能 ， 我 们 需要 在 配置 中 心 的 运行 环境 中 安装 
不 限 长 度 的 ”JCE 版 本 (Unlimited Strength Java Cryptography 
Extension) 。 昌 然 ，JCE 功 能 在 JRE 中 自 带 ， 但 是 默认 使 用 的 是 有 长 度 
限制 的 版 本 。 我 们 可 以 从 Oracle 的 官方 网 站 下 载 到 它 ， 它 是 一 个 压缩 
包 ， 解 压 后 可 以 看 到 下 面 三 个 文件 : 

README.txt 

local_policy.jar 

US_export_policy.jar 

我 们 需要 将 local_policy.jar 和 US_export_policy.jar 两 个 文件 复制 到 
$JAVA_HOME/jre/lib/security 目 录 下 ， 禾 新 原来 的 默认 内 容 。 到 这 里 ， 
加 密 解 密 的 准备 工作 就 完成 了 。 

相关 端点 

在 完成 了 JCE 的 安装 后 ， 可 以 尝试 启动 配置 中 心 。 在 控制 台中 ， 将 会 
输出 一 些 配 置 中 心 特 有 的 端点 ， 主 要 包括 如 下 几 个 。 

e/encryptstatus: 查看 加 密 功 能 状态 的 端点 。 

e/key: 查看 密 钥 的 端点 。 

e/encrypt: 对 请 求 的 body 内 容 进 行 加 密 的 端点 。 

e/decrypt: 对 请 求 的 body 内 容 进行 解密 的 端点 。 

可 以 尝试 通过 GET 请 求 访问 /encrypt/status 端 点 ， 我 们 将 得 到 如 下 内 
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{ 

} 

"description": "No key was installed for encryption service", 
"status": "NO_KEY" 


该 返回 信息 说 明 当 前 配置 中 心 的 加 密 功 能 还 不 能 使 用 ， 因 为 没有 为 
加 密 服务 配置 对 应 的 密 钥 。 

配置 密 钥 

我 们 可 以 通过 encrypt.key 属 性 在 配置 文件 中 直接 指定 密 钥 信息 (对 称 
性 密 钥 ) ， 比 如 

encrypt.key=didispace 

加 入 上 述 配 置信 息 后 ， 重 启 配置 中 心 ， 再 访问 /encryptstatus 端 点 ， 
我 们 将 得 到 如 下 内 容 : 

{ 

"status": "OK" 


} 

此 时 ， 我 们 配置 中 心 的 加 密 解密 功能 就 已 经 可 以 使 用 了 ， 不 妨 尝 试 
访问 一 下 /encrypt 和 /decrypt 诺 点 来 使 用 加 密 和 解密 的 功能 。 注 意 ， 这 两 
个 端点 都 是 POST 请 求 ， 加 密 和 解密 信息 需要 通过 请 求 体 来 发 送 。 比 
如 ， 以 cunl 命令 为 例 ， 我 们 可 以 通过 下 面 的 方式 调用 加 密 与 解密 端点 : 

$ curl localhost:7001/encrypt-d didispace 

3c70a809bfa24ab88bcb5e1ldf51cb9e4dd4b8fec88301eb7a18177f1769c84' 

80be2c99406ae28c7 

$ curl localhost:7001/decrypt-d 

3c70a809bfa24ab88bcb5e1ldf51cb9e4dd4b8fec88301eb7a18177f1769c84' 

2C99406ae28c7 

didispace 

这 里 ， 我 们 通过 配置 encrypt.key 参 数 来 指定 密 钥 的 实现 方式 采用 了 对 
称 性 加 密 。 这 种 方式 实现 起 来 比较 简单 ， 只 需要 配置 一 个 参数 即 可 。 另 
外 ， 我 们 也 可 以 使 用 环境 变量 ENCRYPT_KEY 来 进行 配置 ， 让 密 钥 信息 
外 部 化 存储 。 

非 对 称 加 密 

Spring Cloud Config 的 配置 中 心 不 仅 可 以 使 用 对 称 性 加 密 ， 也 可 以 使 
用 非 对 称 性 加 密 〈 比 如 RSA 密 钥 对 ) 。 虽 然 非 对 称 性 加 密 的 密 钥 生成 与 
配置 相对 复杂 一 些 ， 但 是 它 具 有 更 高 的 安全 性 。 下 面 ， 我 们 来 具体 介绍 
一 下 如 何 使 用 非 对 称 加 密 。 

首先 ， 需 要 通过 keytool 工 具 来 生成 密 钥 对 。keytoo] 是 JDK 中 的 一 个 
密 钥 和 证 书 管理 工具 。 它 使 用 户 能 够 管理 自己 的 公 钥 / 私 钥 对 及 相关 证 
书 ， 用 于 “通过 数字 签名 〉 自 我 认证 (用户 同 其 他 用 户 /服务 认证 自 
己 ) 或 数据 完整 性 以 及 认证 服务 。 在 JDK ”1.4 以 后 的 版 本 中 都 包含 了 这 
一 工具 ， 它 的 位 置 在 %JAVA_HOME%\bin\keytool.exe。 

生成 密 钥 的 具体 命令 如 下 所 示 : 





























$ keytool-genkeypair-alias config-server-keyalg RSA-keystore config- 


server.keystore 


日 
XE 


输入 密 钥 库 口令 : 

再 次 输入 新 口令 : 

您 的 名 字 与 姓氏 是 什么 ? 

[Unknown|: zhaiyongchao 

您 的 组 织 单位 名 称 是 什么 ? 
[Unknownj]: company 

您 的 组 织 名 称 是 什么 ? 

[Unknownj]: organization 

您 所 在 的 城市 或 区 域名 称 是 什么 ? 
[Unknownj]: city 

您 所 在 的 省 /市 /自治 区 名 称 是 什么 ? 
[Unknownj]: province 

该 单位 的 双 字 母国 家 /地 区 代码 是 什么 ? 
[Unknownl: china 
CN=zhaiyongchao,OU=company,O=organization,L=city,ST=province,C= 








否 正 确 ? 


合 ]:y 

输入 <config-server> 的 密 钥 口令 

《如果 和 和 密 钥 库 口 令 相 同 ， 按 回 车 ) : 

再 次 输入 新 口令 : 

另外， 如 果 不 想 逐步 输入 那些 提示 信息 ， 可 以 使 用 -dname 来 直接 指 





定 ， 而 密 钥 库 口令 与 密 钥 口令 可 使 用 -storepass 和 -keypass 来 直接 指定 。 
所 以 ， 我 们 可 以 通过 下 面 的 命令 直接 创建 出 与 上 述 命 令 一 样 的 密 钥 库 : 


$ keytool-genkeypair-alias config-server-keyalg RSA \ 
-dname 


"CN=zhaiyongchao,OU=company,O=organization,L=city,ST=province,C=ch 


\ 


-keypass 222222\ 

-keystore config-server.keystore \ 

-storepass 111111\ 

默认 情况 下 ， 使 用 上 述 命令 创建 的 密 钥 只 有 90 天 有 效 期 。 如 果 想 要 


调整 它 的 有 效 期 ， 可 以 通过 增加 -validity 参 数 来 实现 ， 比 如 我 们 可 以 通 


过 下 面 的 命令 ， 让 密 钥 的 有 效 期 延长 到 一 年 : 


$ keytool-genkeypair-alias config-server-keyalg RSA \ 
-dname 


"CN=zhaiyongchao,OU=company,O=organization,L=city,ST=province,C=ch 
\ 

-keypass 222222\ 

-keystore config-server.keystore \ 

-storepass 111111\ 

-validity 365 \ 

上 述 的 三 种 命令 生成 方式 ， 最 终 都 会 在 命令 的 当前 执行 目录 下 生成 
一 个 configserver.keystore 文 件 。 下 面 ， 我 们 需要 将 它 保存 在 配置 中 心 的 
文件 系统 中 的 某 个 位 置 ， 比 如 放 在 当前 的 用 户 目 录 下 ， 然 后 在 配置 中 心 
中 加 入 相关 的 配置 信息 : 

encrypt.key-store.location=file://${user.home}/config-server.keystore 

encrypt.key-store.alias=config-server 
encrypt.key-store.password=111111 

encrypt.key-store.secret=222222 

如 果 我 们 将 config-server.keystore 放 在 配置 中 心 的 src/main/resource 目 
录 下 ， 也 可 以 直接 这 样 配置 : encrypt.key-store.location=config- 
server.keystore。 男 外 ， 非 对 称 加 密 的 配置 信息 也 可 以 通过 环境 变量 的 方 
式 进行 配置 ， 它 们 对 应 的 具体 变量 名 如 下 : 

ENCRYPT_KEY_STORE LOCATION 

ENCRYPT_KEY_STORE ALIAS 

ENCRYPT_KEY_STORE PASSWORD 

ENCRYPT_KEY_STORE_ SECRET 

通过 环境 变量 来 配置 密 钥 库 相 关 信 息 可 以 获得 更 好 的 安全 性 ， 所 以 
我 们 将 敏感 的 口令 信息 存储 在 配置 中 心 的 环境 变量 中 是 一 种 不 错 的 选 























当 要 将 配置 中 心 部 署 到 生产 环境 中 时 ， 与 服务 注册 中 心 一 样 ， 我 们 
也 希望 它 是 一 个 高 可 用 的 应 用 。Spring Cloud _ Config 实现 服务 端的 高 可 
用 非常 简单 ， 主 要 有 以 下 两 种 方式 。 

e 传 统 模式 : ”不 需要 为 这 些 服务 问 做 任何 额外 的 配置 ， 只 需要 遵守 
一 个 配置 规则 ， 将 所 有 的 Config Server 都 指向 同一 个 Git 仓 库 ， 这 样 所 有 
的 配置 内 容 就 通过 统一 的 共享 文件 系统 来 维护 。 而 客户 端 在 指定 Config 
Server 位 置 时 ， 只 需要 配置 Config Server 上 层 的 负载 均衡 设备 地 址 即 
可 ， 就 如 下 图 所 示 的 结构 。 





e 服 务 模式 : 除了 上 面 这 种 传统 的 实现 模式 之 外 ， 我 们 也 可 以 将 
Config ”Server 作 为 一 个 普通 的 微服 务 应 用 ， 纳 入 Eureka 的 服务 治理 体系 
中 。 这 样 我们 的 微服 务 应 用 就 可 以 通过 配置 中 心 的 服务 名 来 获取 配置 信 
恩 ， 这 种 方式 比 起 传统 的 实现 模式 来 说 更 加 有 利于 维护 ， 因 为 对 于 服务 
端的 负载 均衡 配置 和 客户 端的 配置 中 心 指定 都 通过 服务 治理 机 制 一 并 解 
决 了 ， 既 实现 了 高 可 用 ， 也 实现 了 目 维护 。 由 于 这 部 分 的 实现 需要 客户 
具体 示例 读者 可 详细 阅读 “客户 端详 解 ” 一 节 中 的 “服务 化 配 

心 ”小 节 。 








安 户 i 详 解 

在 学 习 了 关于 Spring Cloud Config 服 务 端的 大 量 配置 和 使 用 细节 之 
后 ， 接 下 来 我 们 将 通过 本 内 容 继续 学 习 Spring Cloud Config 客 户 并 的 
使 用 与 配置 。 


URI 指 定 心 





Spring ”Cloud ”Config 的 客户 端 在 启动 的 时 候 ， 默 认 会 从 工程 的 
classpath 中 加 载 配置 信息 并 局 动 应 用 。 只 有 当 我 们 配置 
Spring.cloud.config.uri 的 时 候 ， 客 户 端 应 用 才 会 答 试 连接 Spring Cloud 
Config 的 服务 端 来 获取 远程 配置 信息 并 初始 化 Spring 环境 配置 。 同 时 ， 
我 们 必须 将 该 参数 配置 在 bootstrap.properties、 环 境 变 量 或 是 其 他 优先 级 
高 于 应 用 Jar 包 内 的 配置 信息 中 ， 才 能 正确 加 载 到 远程 配置 。 奉 不 指定 
spring.cloud.config.uri 参数 的 话 ，Spring Cloud Config 的 客户 端 会 默认 洽 
试 连接 http://localhost:8888。 

在 之 前 的 快速 入 门 示例 中 ， 我 们 就 是 以 这 种 方式 实现 的 ， 就 如 下 面 
的 配置 ， 其 中 spring.application.name 和 spring.cloud.config.profile 用 于 定 
位 配置 信息 。 

spring.application.name=didispace 

spring.cloud.config.profile=dev 

spring.cloud.config.uri=http://localhost:7001/ 








务 化 配置 中 心 


在 第 3 章 中 ， 我 们 已 经 学 会 了 如 何 构建 服务 注册 中 心 、 如 何 发 现 与 注 
册 服 务 。 那 么 Config Server 是 否 也 能 以 服务 的 方式 注册 到 服务 中 心 ， 并 
被 其 他 应 用 所 发 现 来 实现 配置 信息 的 获取 呢 ? 答 案 是 肯定 的 。 在 Spring 
Cloud 中 ， 我 们 也 可 以 把 Config Server 视 为 微服 务 架 构 中 与 其 他 业务 服务 

样 的 一 个 基本 单元 。 

下 面 ， 我 们 就 来 详细 介绍 如 何 将 Config Server 注 册 到 服务 中 心 ， 并 通 
过 服务 发 现 来 访问 Config Server 并 获取 Git 仓库 中 的 配置 信息 。 下 面 的 
内 容 将 基于 快速 入 门 中 实现 的 config-server 和 config-client 工 程 来 进行 改 
造 实现 。 

服务 端 配 置 








e 在 config-server 的 pom.xml 中 增加 spring-cloud-starter-eureka 依 赖 ， 以 
实现 将 分 布 式 配 置 中 心 加 入 Eureka 的 服务 治理 体系 。 

<dependencies> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-config-server</artifactId> 

</dependency> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-eureka</artifactId> 


</dependency> 
</dependencies> 
e 在 application.properties 中 配置 参数 


eureka.client.serviceUrl.defaultZone 以 指定 服务 注册 中 心 的 位 置 ， 详 细 内 
容 如 下 : 

spring.application.name=config-server 

server.port=7001 

# 配置 服务 注册 中 心 

eureka.client.serviceUTrl.defaultZone=http://localhost:1111/eureka/ 

# Git 管 理 配 置 

spring.cloud.config.server.git.uri=http://git.oschina.net/didispace/SpringC] 
Learning/ 

spring.cloud.config.server.git.searchPaths=spring_cloud_in_action/config: 
repo 

spring.cloud.config.server.git.username=username 

spring.cloud.config.server.git.password=password 

e 在 应 用 主 类 中 ， 新 增 @EnableDiscoveryClient 注 解 ， 用 来 将 config- 
server 注 册 到 上 面 配置 的 服务 注册 中 心 上 去 。 

EnableDiscoveryCjient 

@EnableConfigServer 

SpringBootApplication 

public class Application { 

public static void main (String[largs) { 

new 
SpringApplicationBuilder (Application.class) .web (true) .run (args) ;} 


} 
e 启 动 该 应 用 ， 并 访问 http://localhost:1111/， 可 以 在 Eureka Server 的 
言 息 面 板 中 看 到 config-server 已 经 被 注册 了 。 


客户 端 配置 

e 在 config-client 的 pom.xml 中 新 增 spring-cloud-starter-eureka 依 赖 ，L 
实现 客户 端 发 现 config-server 服 务 ， 具 体 配置 如 下 : 

<dependencies> 

<dependency> 

<groupId>org.Springframework.boot</groupId> 

<artifactId>spring-boot-starter-web</artifactId> 

</dependency> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-config</artifactId> 

</dependency> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-eureka</artifactId> 

</dependency> 

</dependencies> 





e 在 bootstrap.properties 中 ， 按 如 下 配置 : 

Spring.application.name=didispace 

server.port=7002 

eureka.client.serviceUTrl.defaultZone=http://localhost:1111/eureka/ 

spring.cloud.config.discovery.enabled=true 

spring.cloud.config.discovery.serviceld=config-server 

ne cloud.config.profile=dev 

其 中 ， 通 过 eureka.client.serviceUrl.defaultZone 参 数 指定 服务 注册 中 

心 ， 用 于 服务 的 注册 与 发 现 ， 再 将 spring.cloud.config.discovery.enabled 
参数 设置 为 tue， 开 启 通 过 服务 来 访问 Config ”Server 的 功能 ， 最 后 利用 
spring.cloud.config.discovery.serviceld 参 数 来 指定 Config ”Server 注 册 的 服 
务 名 。 这 里 的 spring.application.name 和 spring.cloud.config.profile 如 之 前 
通过 URI 的 方式 访问 的 时 候 一 样 ， 用 来 定位 Git 中 的 资源 。 

e 在 应 用 主 类 中 ， 增 加 @EnableDiscoveryClient 注 解 ， 用 来 发 现 


config-server 服 务 ， 利 用 其 来 加 载 应 用 配置 : 
@EnableDiscoveryCljlient 
SpringBootApplication 
public class Application { 
public static void main (String[largs) { 
new 
SpringApplicationBuilder (Application.class) .web (true) .run Cargs) ; 
} 


} 

e 沿 用 之 前 我 们 创建 的 Controller 来 加 载 Git 中 的 配置 信息 : 
@RefreshScope 

(DRestController 

public class TestController { 

@Value ("${from}") 

private String from; 

@RequestMapping ("/from") 

public String from () { 

return this.from:; 


} 


} 

e 完 成 上 述 配置 之 后 ， 我 们 局 动 该 客户 端 应 用 。 知 启动 成 功 ， 访 问 
http://localhost:1111/， 可 以 在 Eureka ”Server 的 信息 面板 中 看 到 该 应 用 已 
经 被 注册 成 功 。 


e 访 问 客户 端 应 用 提供 的 服务 http://localhost:7002/from， 此 时 ， 我 们 
会 返回 在 Git 仓 库 中 didispace-dev.properties 文 件 中 配置 的 from 属 性 内 


i 


容 ; "git-dev-1.0"。 
失败 快速 啊 应 与 重 试 


Spring Cloud Config 的 客户 端 会 预先 加 载 很 多 其 他 信息 ， 然 后 再 开始 
连接 Config ”Server 进 行 属性 的 注入 。 当 我 们 构建 的 应 用 较为 复杂 的 时 
候 ， 可 能 在 连接 Config Server 之 前 花费 较 长 的 启动 时 间 ， 而 在 一 些 特殊 
场景 下 ， 我 们 又 希望 可 以 快速 知道 当前 应 用 是 人 否 能 顺利 地 从 Config 
Server 获 取 到 配置 信息 ， 这 对 在 初期 构建 调试 环境 时 ， 可 以 减少 很 多 等 
竺 局 动 的 时 间 。 要 实现 客户 端 优先 判断 Config Server 获 取 是 否 正 常 ， 并 
快速 响应 失败 内 容 ， 只 需 在 bootstrap.properties 中 配置 参数 














Spring.cloud.config.failFast=true 即 可 。 

我 们 可 以 实验 一 下 ， 在 未 配置 该 参数 前 ， 不 启动 Config Server， 直 接 
局 动 客户 并 应 用 ， 可 以 获得 下 面 的 报错 信息 。 同 时 ， 在 报错 之 前 ， 可 以 
看 到 客户 端 应 用 已 经 加 载 了 很 多 内 容 ， 比 如 Controller 的 请 求 等 。 

org.springframework.beans.factory.BeanCreationException: Error 
creating bean with name 'scopedTarget.testController': Injection of autowired 
dependencies failed; 

加 上 spring.cloud.config.failFast=true 参 数 之 后 ， 再 启动 客户 端 应 用 ， 
可 以 获得 下 面 的 报错 信息 ， 并 且 前 置 的 加 载 内 容 少 了 很 多 ， 这 样 通过 该 
参数 有 效 避 免 了 当 Config Server 配 置 有 误 时 ， 不 需要 多 等 待 前 置 的 一 些 
加 载 时 间 ， 实 现 了 快速 返回 失败 信息 。 

java.lang.IHegalstateEXception: Could not locate PropertySource and the 
fail fast property is set,failing 

上 面 ， 我 们 演示 了 当 Config Server 宕 机 或 是 客户 端 配 置 不 正确 导致 连 
接 不 到 而 启动 失败 的 情况 ， 快 速 啊 应 的 配置 可 以 及 挥 比较 好 的 效果 。 但 
是 ， 硝 只 是 因为 网 络 波动 等 其 他 间 葡 性 原因 导致 的 问题 ， 直 接 启 动 失败 
似乎 代价 有 些 高 。 所 以 ，Config 客户 端 还 提供 了 自动 重 试 的 功能 ， 在 开 
启 重 斌 功能 前 ， 先 确保 已 经 配置 了 spring.cloud.config.failFast=true， 再 
进行 下 面 的 操作 。 

e 在 客户 端的 pom.xml 中 增加 spring-retry 和 spring-boot-starter-aop 依 
赖 ， 具 体 如 下 : 


<dependencies> 




















ee ee。 


<dependency> 

<groupId>org.Springframework.retry</groupId> 

<artifactId>spring-retry</artifactId> 

</dependency> 

<dependency> 

<groupId>org.Springframework.boot</groupId> 

<artifactId>spring-boot-starter-aop</artifactId> 

</dependency> 

</dependencies> 

e 不 需要 再 做 其 他 任何 配置 ， 局 动 客户 端 应 用 ， 在 控制 台中 可 以 看 到 
如 下 内 容 。 客 户 端 在 连接 Config Server 失 败 之 后 ， 会 继续 尝试 ， 直 到 第 6 
次 失败 后 ， 才 返回 错误 信息 。 通 过 这 样 的 重 试 机 制 ， 可 以 避免 一 些 间 区 
性 问题 引起 的 失败 导致 客户 端 应 用 无 法 启动 的 情况 。 





c.c.C.ConfigServicePropertySourceLocator : Fetching config from server 
at: 

http://PC-201602152056:7001/ 

c.c.C.ConfigServicePropertySourceLocator : Fetching config from server 
at: 

http:/PC-201602152056:7001/ 

c.c.C.ConfigServicePropertySourceLocator : Fetching config from server 
at: 

http:/PC-201602152056:7001/ 

c.c.C.ConfigServicePropertySourceLocator : Fetching config from server 
at: 

http://PC-201602152056:7001/ 

c.c.C.ConfigServicePropertySourceLocator : Fetching config from server 
at: 

http://PC-201602152056:7001/ 

c.c.C.ConfigServicePropertySourceLocator : Fetching config from server 
at: 

http://PC-201602152056:7001/ 

0.s.boot.SpringApplication : Application startup failed 

java.lang.IHegalstateEXception: Could not locate PropertySource and the 
fail fast property is set,failing 

各 对 默认 的 最 大 重 试 次 数 和 重 试 间 隔 等 设置 不 满意 ， 还 可 以 通过 下 
面 的 参数 进行 调整 。 

espring.cloud.config.retry.multiplier: 初始 重 试 间隔 时 间 〈 单 位 为 毫 
秒 ) ， 默 认为 1000 坚 秒 。 

espring.cloud.config.retry.initial-interval: 下 一 间隔 的 乘 数 ， 默 认为 
1.1， 所 以 当 最 初 间隔 是 1000 毫 秒 时 ， 下 一 次 失败 后 的 间隔 为 1100 训 
秒 。 

espring.cloud.config.retry.max-interval: 最 大 间隔 时 间 ， 默 认为 2000 
室 秒 。 

espring.cloud.config.retry.max-attempts: 最 大 重 试 次 数 ， 默 认为 6 








坎 a 
区 取 远程 配置 


在 入 门 示例 中 ， 我 们 对 {fapplication}、{profile}、{label} 这 些 参数 已 
经 有 了 一 定 的 了 解 。 在 Git 仓库 中 ， 一 个 形 如 {application}- 


{profile}.properties ”或 {application}-{profile}.yml 的 配置 文件 ， 通 过 URL 
请 求 和 客户 端 配置 的 访问 对 应 可 以 总 结 如 下 。 

e 通 过 加 Config Server 发 送 GET 请 求 以 直接 的 方式 获取 ， 可 用 下 面 的 
链接 形式 。 

四 不 带 {label} 分 文 信息 ， 默 认 访问 master 分 文 ， 可 使 用 : 

D/{application}-{profile}.yml 

DD/{application}-{profile}.properties 

国 闻 {label} 分 文 信息 ， 可 使 用 : 

D/{label}/{application}-{profile}.yml 

DD/{application}/{profile}[/{label}] 

D/{label}/{application}-{profile}.properties 

e 通 过 客户 闹 配 置 方 式 加 载 的 内 容 如 下 所 示 。 

spring.application.name: 对 应 配置 文件 中 的 {application} 内 容 。 

加 spring.cloud.config.profile: 对 应 配置 文件 中 {profile} 内 容 。 

加 spring.cloud.config.label: 对 应 分 文 内 容 ， 如 不 配置 ， 默 认为 
master。 


动态 刷新 配置 


有 时 候 ， 我 们 需要 对 配置 内 容 做 一 些 实 时 更 新 ， 那 么 Spring Cloud 
Config 是 否 可 以 实现 呢 ? 答案 显然 是 可 以 的 。 下 面 ， 我 们 以 快速 入 门 中 
的 示例 作为 基础 ， 看 看 如 何 进行 改造 来 实现 配置 内 容 的 实时 更 新 。 

首先 ， 回 顾 一 下 ， 当 前 我 们 已 经 实现 了 哪些 内 容 。 

econfig-repo: 定义 在 Git 仓 库 中 的 一 个 目录 ， 其 中 存储 了 应 用 名 为 
didispace 的 多 环境 配置 文件 ， 配 置 文 件 中 有 一 个 from 参 数 。 

econfig-server: 配置 了 Git 仓 库 的 服务 端 。 

econfig-client: 指定 了 config-server 为 配置 中 心 的 客户 端 ， 应 用 名 为 
didispace， 用 来 访问 配置 服务 器 以 获取 配置 信息 。 该 应 用 中 提供 了 一 
个 /from 接 口 ， 它 会 获取 config-repo/didispace-dev.properties 中 的 from 属 性 
返回 。 

在 改造 程序 之 前 ， 我 们 先 将 config-server 和 config-client 都 启动 起 来 ， 
并 访问 客户 端 提 供 的 REST ”接口 http://localhost:7002/from 来 获取 配置 信 
轧 ， 获 得 的 返回 内 容 为 gitrdev-1.0。 接 着 ， 我 们 可 以 答 试 使 用 Git 工 具 修 
改 当 前 配置 的 内 容 ， 比 如 ， 将 config-repo/didispace-dev.properties 中 的 
from 的 值 从 from=gitdev-1.0 修 改 为 from=git-dev-2.0， 再 访问 
http://localhost:7002/from， 可 以 看 到 其 返回 内 容 还 是 git-dev-1.0。 

接 下 来 ， 我 们 将 在 config-client 端 做 一 些 改造 以 实现 配置 信息 的 动态 




















刷新 。 
e 在 config-client 的 pom.xml 中 新 增 spring-boot-starter-actuator 监 控 模 
块 。 其 中 包含 了 /refresh ”端点 的 实现 ， 该 端点 将 用 于 实现 客户 端 应 用 配 
置信 息 的 重新 获取 与 刷新 。 

<dependency> 

<groupId>org.Springframework.boot</groupId> 

<artifactId>spring-boot-starter-actuator</artifactId> 

</dependency> 

e 重 新 启动 config-client， 访 问 一 次 http:/localhost:7002/from， 可 以 看 
到 当前 的 配置 值 。 

e 修 改 Git 仓 库 config-repo/didispace-dev.properties 文 件 中 from 的 值 。 

e 再 访问 一 次 http://localhost:7002/from， 可 以 看 到 配置 值 没 有 改变 。 

e 通 过 POST 请 求 发 送 到 http://localhost:7002/refresh， 我 们 可 以 看 到 
返回 内 容 如 下 ， 代 表 from 参 数 的 配置 内 容 被 更 新 了 : 

[ 

"from" 

] 

e 再 访问 一 次 http://localhost:7002/from， 可 以 看 到 配置 值 已 经 是 更 新 
后 的 值 了 。 

通过 上 面 的 介绍 ， 大 家 不 难 想 到 ， 该 功能 还 可 以 同 Git 仓 库 的 Web 
Hook 功 能 进行 关联 ， 当 有 Git ”提交 变化 时 ， 就 给 对 应 的 配置 主机 发 
送 /refresh 请求 来 实现 配置 信息 的 实时 更 新 。 但 是 ， 当 我 们 的 系统 发 展 
壮大 之 后 ， 维 护 这 样 的 刷新 清单 也 将 成 为 一 个 非常 大 的 负担 ， 而 且 很 容 
易 犯 错 ， 那 么 有 什么 办 法 可 以 解决 这 个 复杂 度 呢 ?后 续 我 们 将 介绍 如 何 
通过 Spring Cloud Bus 来 实现 以 消息 总 线 的 方式 进行 配置 变更 的 通知 ， 并 
完成 集群 上 的 批量 配置 更 新 。 














第 9 章 消 忆 总 线 : Spring Cloud Bus 


在 微服 务 架 构 的 系统 中 ， 我 们 通常 会 使 用 轻 量 级 的 消息 代理 来 构建 
一 个 共用 的 消息 主题 让 系统 中 所 有 微服 务实 例 都 连接 上 来 ， 由 于 该 主题 
中 产生 的 消息 会 被 所 有 实例 监听 和 消费 ， 所 以 我 们 称 它 为 消息 总 线 。 在 
总 线 上 的 各 个 实例 都 可 以 方便 地 广播 一 些 需要 让 其 他 连接 在 该 主题 上 的 
实例 都 知道 的 消 妃 ， 例 如 配置 信息 的 变更 或 者 其 他 一 些 管理 操作 等 。 

由 于 消 息 总 线 在 微服 务 架构 系统 中 被 广泛 使 用 ， 所 以 它 己 同 配置 中 心 
二 几乎 是 微服 务 典 构 中 的 必 备 组 件 。Spring ”Cloud 作 为 微服 务 染 构 
综合 性 的 解决 方案 ， 对 此 自然 也 有 上 自己 的 实现 ， 这 束 是 本 章 我 们 将 要 具 
体 介 绍 的 Spring Coil Bus。 通 过 使 用 Spring Cloud Bus， 可 以 非常 容易 
地 搭建 起 消 恩 总 线 ， 同 时 实现 了 一 些 消息 总 线 中 的 常用 功能 ， 比 如 ， 配 
合 Spring Cloud Config 实 现 微服 务 应 用 配置 信息 的 动态 更 新 等 。 

在 本 章 中 ， 我 们 将 从 消息 代理 的 基础 开始 ， 由 浅 入 深 地 介绍 如 何 使 
用 Spring Cloud Bus 构 建 微服 务 架 构 中 的 消息 总 线 。 








消 [a 代 理 


消息 代理 〈Message Broker) 是 一 种 消息 验证 、 传 输 、 路 由 的 架构 模 
式 。 它 在 应 用 程序 之 间 起 到 通信 调度 并 最 小 化 应 用 之 间 的 依赖 的 作用 ， 
使 得 应 用 程序 可 以 高 效 地 解 称 通 信 过 程 。 消 息 代 理 是 一 个 中 间 件 产品 ， 
它 的 核心 是 一 个 请 妃 的 路 由 程序 ， 用 来 实现 接收 和 分 发 消息 ， 并 根据 设 
定好 的 消 晨 处 理 流 来 转发 给 正确 的 应 用 。 它 包括 独立 的 通信 和 消 乱 传递 
协议 ， 能 够 实现 组 织 内 部 和 组 织 间 的 网 络 通 信 。 设 计 代理 的 目的 就 是 为 
了 能 够 从 应 用 程序 中 传 入 消 已 ， 并 执行 一 些 特别 的 操作 ， 下 面 这 些 是 在 
企业 应 用 中 ， 我 们 经 党 需要 使 用 消 明 代理 的 场景 : 

e 将 消息 路 由 到 一 个 或 多 个 目的 地 。 

e 消 息 转 化 为 其 他 的 表现 方式 。 

e 执 行 消息 的 聚集 、 消 息 的 分 解 ， 并 将 结果 发 送 到 它们 的 目的 地 ， 然 
后 重新 组 合 啊 应 返回 给 消息 用 户 。 

e 调 用 Web 服 务 来 检索 数据 。 

e 啊 应 事件 或 错误 。 

e 使 用 及 布 -订阅 模式 来 提供 内 容 或 基于 主题 的 消息 路 由 。 

目前 已 经 有 非常 多 的 开源 产品 可 以 供 大 家 使 用 ， 比 如 : 

eActiveMQ 

eKafka 

e RabbitMQ 

eRocket MQ 














@... 

当前 版 本 的 Spring Cloud Bus 仅 文 持 两 亚 中 间 件 产品 : RabbitMQ 和 
Kafka。 在 下 面 的 章节 中 ， 我 们 将 分 别 介绍 如 何 使 用 这 两 敌 消 息 中 间 件 
与 Spring Cloud Bus 配 合 实现 消息 总 线 。 





RabbitMQ 是 实现 了 高 级 消息 队列 协议 “AMQP) 的 开源 消息 代理 软 
件 ， 也 称 为 面向 消息 的 中 间 件 。RabbitMQ 服务 器 是 用 高 性 能 、 可 伸缩 
而 闻名 的 Erlang 语言 编写 而 成 的 ， 其 集群 和 故障 转移 是 构建 在 开放 电信 
平台 框架 上 的 。 

AMQP 是 Advanced Message Queuing Protocol 的 简称 ， 它 是 一 个 面向 
消息 中 间 件 的 开放 式 标 准 应 用 层 协 议 。 它 定义 了 以 下 这 些 特性 : 

e@ 消 息 方 回 

e 消 息 队 列 

e 消 息 路 由 【包括 点 到 点 和 发 布 -订阅 模式 ) 

e 吕 靠 性 

e 安 全 性 

AMQP 要 求 消息 的 提供 者 和 客户 端 接收 者 的 行为 要 实现 对 不 同 供应 
商 可 以 用 相同 的 方式 (比如 SMTP、HTTP、FTP 等 ) 进行 互相 操作 。 在 
以 往 的 中 间 件 标准 中 ， 主 要 还 是 建立 在 API 级 别 ， 比 如 JMS， 集 中 于 通 
过 不 同 的 中 间 件 实现 来 建立 标准 化 的 程序 间 的 互 操作 性 ， 而 不 是 在 多 个 
中 间 件 产品 间 实 现 互 操作 性 。 

AMQP 与 JMS 不 同 ，JMS 定 义 了 一 个 API 和 一 组 消息 收发 必须 实现 的 
行为 ， 而 AMQP 是 一 个 线路 级 协议 。 线 路 级 协议 描述 的 是 通过 网 络 发 
送 的 数据 传输 格式 。 因 此 ， 任 何 符 合 该 数据 格式 的 消息 发 送 和 接收 工具 
都 能 互相 兼容 和 进行 操作 ， 这 样 承 能 轻易 实现 跨 技 术 平台 的 架构 方案 。 

RabbitMQ 以 AMQP 协 议 实 现 ， 所 以 它 可 以 支持 多 种 操作 系统 、 多 种 
编程 语言 ， 几 乎 可 以 履 盖 所 有 主流 的 企业 级 技术 平台 。 在 微服 务 架 构 消 
上 恩 中 间 件 的 选 型 中 ， 它 是 一 个 非常 适合 且 优 秀 的 选择 。 因 此 ， 在 Spring 
Cloud Bus 中 包含 了 对 Rabbit 的 自动 化 默认 配置 ， 在 下 面 的 章节 中 ， 我 们 
将 先 从 RabbitMQ 的 基础 安装 和 使 用 开始 ， 循 序 渐进 地 学 习 如 何 与 
Spring Cloud Bus 进 行 整合 实现 消息 总 线 。 

















基本 概念 








在 开始 具体 实践 之 前 ， 我 们 先 介绍 一 些 关 于 “RabbitMQ 的 基本 概 
念 ， 为 后 续 的 讲解 做 一 些 必 要 铺垫 〈 如 果 对 于 RabbitMQ 已 经 很 熟悉 的 
读者 可 以 跳 过 本 节 ， 直 接 从 “快速 入 门 ” 一 节 开 始 阅 读 ) 。 

eBroker: 可 以 理解 为 消息 队列 服务 器 的 实体 ， 它 是 一 个 中 间 件 应 


用 ， 负 贡 接 收 消 息 生 产 者 的 消息 ， 然 后 将 消息 发 送 至 消息 接收 者 或 者 其 
他 的 Broker。 

eExchange: 消息 交换 机 ， 是 消息 第 一 个 到 达 的 地 方 ， 消 上 息 通过 它 指 
定 的 路 由 规则 ， 分 发 到 不 同 的 消息 队列 中 去 。 

eQueue: 消息 队列 ， 消 息 通 过 发 送 和 路 由 之 后 最 终 到 达 的 地 方 ， 到 
达 Queue 的 消 奶 即 进 入 逻辑 上 等 竺 消费 的 状态 。 每 个 消息 都 会 被 发 送 到 
一 个 或 多 个 队列 。 

eBinding: 绑 定 ， 它 的 作用 就 是 把 Exchange 和 Queue 按 照 路 由 规则 绑 
定 起 来 ， 也 束 是 Exchange 和 Queue 之 间 的 虚拟 连接 。 

eRouting Key: 路 由 关键 字 ，Exchange 根 据 这 个 关键 字 进 行 消 恩 投 


eVirtual host: 虚拟 主机 ， 它 是 对 Broker 的 虚拟 划分 ， 将 消费 者 、 生 
产 者 和 它们 依赖 的 AMQP 相 关 结 构 进行 隔离 ， 一 般 都 是 为 了 安全 考 虚 。 
0 对 不 同 用 户 进行 权 
限 的 分 离 。 

eConnection: 连接 ， 代 表 生 产 者 、 消 费 者 、Broker 之 间 进 行 通 信 的 
物理 网 络 。 

eChannel: 消息 通道 ， 用 于 连接 生产 者 和 消费 者 的 逻辑 结构 。 在 客 
户 端的 每 个 连接 里 ， 可 建立 多 个 Channel， 每 个 Channel 代 表 一 个 会 话 任 
务 ， 通 过 Channel 可 以 隔离 同一 连接 中 的 不 同 交 互 内 容 。 

eProducer: 消息 生产 者 ， 制 造 消 息 并 发 送 消息 的 程序 。 

eConsumer: 消息 消费 者 ， 接 收 消息 并 处 理 消 息 的 程序 。 

消息 投递 到 队列 的 整个 过 程 大 致 如 下 : 

1. 客 户 端 连 接 到 消息 队列 服务 器 ， 打 开 一 个 Channel。 

2. 客 户 端 声明 一 个 Exchange， 并 设置 相关 属性 。 

3. 客 户 端 声明 一 个 Queue， 并 设置 相关 属性 。 

4. 客 户 端 使 用 Routing “Key， 在 Exchange 和 Queue 之 间 建 立 好 绑 定 关 
系 。 

5. 客 户 端 投递 消息 到 Exchange。 

6.Exchange 接 收 到 消息 后 ， 根 据 消 息 的 Key 和 已 经 设置 的 Binding， 进 
行 消息 路 由 ， 将 消息 投递 到 一 个 或 多 个 Queue 里 。 

Exchange 也 有 几 种 类 型 。 

1.Direct 交 换 机 : 完全 根据 Key 进 行 投递 。 比 如 ， 绑 定时 设置 了 
Routing Key 为 abc， 那 么 客户 端 提 区 的 消息 ， 只 有 设置 了 Key 为 abc 的 才 
会 被 投递 到 队列 。 

2.Topic 交 换 机 : 对 Key 进 行 模式 匹配 后 进行 投递 ， 可 以 使 用 符号 # 匹 
配 一 个 或 多 个 词 ， 符 号 * 匹 配 正 好 一 个 词 。 比 如 ，abc.# 匹 配 














abc.def.ghi,abc.* 只 匹配 abc.def 。 

3.Fanout 交 换 机 : 不 需要 任何 Key， 它 采取 广播 的 模式 ， 一 个 消息 进 
来 时 ， 投 递 到 与 该 交换 机 绑 定 的 所 有 队列 。 

RabbitMQ 文 持 消 奶 的 持久 化 ， 也 就 是 将 数据 写 在 磁盘 上 上。 为 了 数据 
安全 考虑 ， 大 多 数 情况 下 都 会 选择 持久 化 。 消 恩 队 列 持久 化 包括 3 个 部 
思 : 

1.Exchange 持 久 化 ， 在 声明 时 指定 durable=> 1。 

2.Queue 持 久 化 ， 在 声明 时 指定 durable=> 1。 

3. 消 息 持 久 化 ， 在 投递 时 指定 delivery_mode=> 2 (1 是 非 持 久 化 〉。 

如 果 Exchange 和 Queue 都 是 持久 化 的 ， 那 么 它们 之 间 的 Binding 也 是 
持久 化 的 。 如 果 Exchange 和 Queue 两 者 之 间 有 一 个 是 持久 化 的 ， 一 个 是 
非 持久 化 的 ， 就 不 允许 建立 绑 定 。 


| 





在 RabbitMQ 官 网 的 下 载 页 面 https://www.rabbitmq.com/download.html 
中 ， 我 们 可 以 获取 到 针对 各 种 不 同 操作 系统 的 安装 包 和 说 明文 档 。 这 
里 ， 我 们 将 对 几 个 常用 的 平台 进行 一 一 说 明 。 

下 面 我 们 采用 的 是 Erlang 和 RabbitMQ Server 版 本 说 明 : 

eErlang/OTP 19.1 

eRabbitMQ Server 3.6.5 

在 Windows 系 统 中 安装 

1. 安 装 Erlang， 通 过 官方 下 载 页 面 http://www.erlang.org/downloads 获 
取 exe 安 装 包 ， 和 直接 打开 并 完成 安装 。 

2. 安 装 RabbitMQ， 通 过 官方 下 载 页 面 
https://www.rabbitmq.com/download.html 获 取 exe 安 装 包 。 

3. 下 载 完 成 后 ， 直 接 运 行 安装 程序 。 

4.RabbitMQ ”Server 安 装 完成 之 后 ， 会 自动 注册 为 服务 ， 并 以 默认 配 
置 进行 启动 。 


在 Windows 的 安装 过 程 中 ， 有 时 候 会 碰 到 服务 启动 失败 的 情况 ， 通 
党 都 是 由 于 用 户 名 为 中 文 ， 导 致 默认 的 db 和 log 目 录 访 问 出 现 问题 。 要 
解决 该 问题 ， 需 要 先 秋 载 RabbitMQ Server， 然 后 设置 环境 变量 
RABBITMQ_BASE 为 一 个 不 含 中 文 的 路 径 ， 比 如 E:serverrabbitmqd。 最 
后 ， 重 新 安装 RabbitMQ 即 可 。 

在 Mac OS 久 中 安装 

在 Mac OS X 中 使 用 brew 工 具 ， 可 以 很 容易 地 安装 RabbitMQ 的 服务 














端 ， 只 需 按 如 下 命令 操作 即 可 : 

1. 将 brew 更 新 到 最 新 版 本 ， 执 行 brew update 合 Ns 

2. 安 装 Erlang， 执 行 brew install erlang 命 令 。 

3. 安 装 RabbitMQ 执行 brew install rabbitmdq 命 令 

通过 执行 上 面 的 命令 ，RabbitMQ Server 会 被 安装 到 /usr/local/sbin， 
并 不 会 自动 加 到 用 户 的 环境 变量 中 去 ， 所 以 我 们 需要 在 .bash_profile 
或 .profile 文 件 中 增加 下 面 的 内 容 : 

PATH=$PATH:/usr/local/sbin 

这 样 ， 就 可 以 通过 rabbitmq-server 命 令 来 启动 RabbitMQ 的 服务 端 了 。 

在 Ubuntu 中 安装 

在 Ubuntu 中 ， 我 们 可 以 使 用 APT 仓 库 来 进行 安装 : 

1. 安 装 Erlang， 执行 apt-get install erlang 命 令 。 

2. 执 行 下 面 的 命令 ， 新 增 APT 仓 库 到 /etc/apt/sources.list.d: 

echo 'debhttp://www.rabbitmqg.com/debian/testing main | 

Sudo tee /etc/apt/sources.list.d/rabbitmgq.list 

3. 更 新 APT 仓 库 的 package list， 执 行 sudo apt-get update 命 令 。 

4. 安 装 Rabbit Server， 执 行 sudo apt-get install rabbitmq-server 命 令 。 

Rabbit 管 理 

我 们 可 以 直接 通过 访问 配置 文件 进行 管理 ， 也 可 以 通过 访问 Web 进 
行 管理 。 下 面 将 介绍 如 何 通 过 Web 进 行 管理 

e 执 行 rabbitmq-plugins enable rabbitmq . 命令 ， 开 司 Web 

管理 插件 ， 这 样 就 可 以 通过 浏览 器 来 进行 管理 了 。 

> rabbitmq-plugins enable rabbitmdq_management 

The following plugins have been enabled: 

mochiweb 

webmachine 

rabbitmq_web_dispatch 

amqp_client 

rabbitmq_management agent 

rabbitmq_ management 

Applying plugin configuration to rabbit@PC-201602152056...started 6 
plugins. 

e 打 开 浏 览 器 并 访问 http://localhost:15672/， 并 使 用 默认 用 户 guest 登 
录 ， 密 码 也 为 guest。 可 以 看 到 如 下 图 所 示 的 管理 页 面 : 


从 图 中 我 们 可 以 看 到 之 前 章节 中 提 到 的 一 | 比如 
Connections、Channels、Exchanges、Queues 等 。 第 一 次 使 用 的 读者 ， 可 








以 点 开 各 项 看 看 都 有 些 什 么 内 容 ， 熟 悉 一 下 RabbitMQ Server 的 服务 端 。 
e 单 击 Admin 选 项 卡 ， 如 下 图 所 示 ， 可 以 尝试 创建 一 个 名 为 
springcloud 的 用 户 。 


其 中 ，Tags 标 签 是 RabbitMQ 中 的 角色 分 类 ， 共 有 下 面 几 种 。 
enone: 不 能 访问 management plugin。 
emanagement: 用 户 可 以 通过 AMQP 做 的 任何 事 外 加 如 下 内 容 。 
量 列 出 自己 可 以 通过 AMQP 登 入 的 virtual hosts。 
国 查 看 上 自己 的 virtual hosts 中 的 queues、exchanges 和 bindings。 
四 查看 和 关闭 自己 的 channels 和 connections 。 
四 但 看 有 关上 自己 的 virtual hosts 的 “全 局 ”统计 信息 ， 包 含 其 他 用 户 在 这 
些 virtual hosts 中 的 活动 。 
epolicymaker:management 可 以 做 的 任何 事 外 加 如 下 内 容 。 
四 查看 、 创 建 和 删除 自己 的 virtual hosts 所 属 的 policies 和 parameters。 
emonitoring:management 可 以 做 的 任何 事 外 加 如 下 内 容 。 
加 列 出 所 有 virtual hosts， 包 括 它 们 不 能 登录 的 virtual hosts。 
加 查看 其 他 用 户 的 connections 和 channels。 
四 查看 节点 级 别 的 数据 ， 如 clustering 和 memory 的 使 用 情况 。 
四 查看 真正 的 关于 所 有 virtual hosts 的 全 局 的 统计 信息 。 
eadministrator:policymaker 和 monitoring 可 以 做 的 任何 事 外 加 如 下 内 
容 s 
四 创建 和 删除 virtual hosts 。 
四 查看、 创建 和 删除 users。 
四 全 看 、 创 建 和 删除 permissions。 
四 关闭 其 他 用 户 的 connections。 


快 速 和 门 


接 下 来 ， 我 们 通过 在 Spring Boot 应 用 中 整合 RabbitMQ， 实 现 一 个 简 
单 的 发 送 、 接 收 消息 的 例子 来 对 RabbitMQ 有 一 个 直观 的 感受 和 理解 。 

在 Spring Boot 中 整合 RabbitMQ 是 一 件 非 常 容易 的 事 ， 因 为 之 前 我 们 
已 经 介绍 过 Starter POMSs， 其 中 的 AMQP 模 块 残 可 以 很 好 地 文 持 
RabbitMQ， 下 面 我 们 就 来 详细 说 说 整合 过 程 。 

e 新 建 一 个 Spring Boot 工 程 ， 命 名 为 rabbitmq-hello。 

e 在 pom.xml 中 引入 如 下 依赖 内 容 ， 其 中 spring-boot-starter-amqp 用 
于 支持 RabbitMQ 。 

<parent> 


<groupId>org.Springframework.boot</groupId> 
<artifactId>spring-boot-starter-parent</artifactId> 
<version>1.3.7.RELEASE</version> 
<relativePath/> <!--lookup parent from repository--> 
</parent> 

<dependencies> 

<dependency> 
<groupId>org.Springframework.boot</groupId> 
<artifactId>spring-boot-starter-amqp</artifactId> 
</dependency> 

<dependency> 
<groupId>org.Springframework.boot</groupId> 
<artifactId>spring-boot-starter-test</artifactId> 
<scope>test</scope> 

</dependency> 

</dependencies> 


e 在 application.properties 中 配置 关于 RabbitMQ 的 连接 和 用 户 信 息 ， 这 





里 我 们 使 用 之 前 安装 时 创建 的 springcloud。 若 没有 自己 的 用 户 ， 可 以 回 


到 上 和 面 的 安装 内 容 ， 在 管理 页 面 中 创建 用 户 。 


spring.application.name=rabbitmq-hello 
Spring.rabbitmq.host=localhost 
Spring.rabbitmq.port=5672 
Spring.rabbitmq.username=springcloud 
Spring.rabbitmq.password=123456 





e 创 建 消 息 生 产 者 Sender。 通 过 注入 AmqpTemplate 接口 的 实例 来 实 


现 消息 的 有 发送，AmqpTemplate 接 口 定义 了 一 套 针对 AMQP 协 议 的 基础 操 





作 。 在 Spring Boot 中 会 根据 配置 来 注入 其 具体 实现 。 在 该 生产 者 中 ， 我 


们 会 产生 一 个 字符 串 ， 并 发 送 到 名 为 hello 的 队列 中 。 


@Component 

public class Sender { 

Autowired 

private AmqpTemplate rabbitTemplate; 
public void send () { 

String context="hello "+new Date (); 
System.out.println ("Sender : "+context) ; 


this.rabbitTemplate.convertAndSend ("hello",context) ; 


} 


} 

e 创 建 消 轧 消费 者 Receiver。 通 过 @RabbitListener 注 解 定义 该 类 对 
hello 队 列 的 监听 ， 并 用 @RabbitHandler 注解 来 指定 对 消息 的 处 理 方法 。 
所 以 ， 该 消费 者 实现 了 对 hello 队 列 的 消费 ， 消 费 操 作为 输出 消息 的 字符 
串 内 容 。 

@Component 

@RabbitListener (queues="hello") 

public class Receiver { 

(CORabbitHandjer 

public void process (String hello) { 

System.out.println ("Receiver : "+hello) ; 





J. 

e 创 建 RabbitMQ 的 配置 类 RabbitConfig， 用 来 配置 队列 、 交 换 器 、 路 
由 等 高 级 信息 。 这 里 我 们 以 入 门 为 主 ， 先 以 最 小 化 的 配置 来 定义 ， 以 完 
成 一 个 基本 的 生产 和 消费 过 程 。 

@Configuration 

public class RabbitConfig { 

Bean 

public Queue helloQueue () { 

return new Queue ("hello"): 


} 


} 

e 创 建 应 用 主 类 。 

SpringBootApplication 

public class HelloApplication { 

public static void main (String[largs) { 
SpringApplication.run (HelloApplication.class,args) ; 


} 

e 创 建 单 元 测试 类 ， 用 来 调用 消息 生产 。 

@RunWith (SpringJUnit4ClassRunner.class) 
@SpringApplicationConfiguration (classes=HelloApplication.class) 
public class HelloApplicationTests { 

(OAutowired 

private Sender Sender; 

(@Test 


public void hello () throws Exception { 
sender.send 〈) ; 


} 


} 

完成 程序 编写 之 后 ， 下 面 开始 尝试 运行 。 首 先 确 保 RabbitMQ Server 
已 经 局 动 ， 然 后 进行 下 面 的 操作 。 

e 局 动 应 用 主 类 ， 从 控制 台中 ， 我 们 可 看 到 如 下 内 容 ， 程 序 创建 了 一 
个 访问 127.0.0.1:5672 中 springcloud 的 连接 。 

0.s.ar.c.CachingConnectionFactory : (Created new connection: 
SimpleConnection(D29836d32 

[delegate=amqp://springcloud(@127.0.0.1:5672/] 

同时 ， 我 们 通过 RabbitMQ 的 控制 面板 ， 可 以 看 到 Connections 和 
Channels 中 包含 当前 连接 的 条 目 。 





e 运 行 单元 测试 类 ， 我 们 可 以 在 控制 台中 看 到 下 面 的 输出 内 容 ， 消 奶 
被 发 送 到 了 RabbitMQ Server 的 hello 队 列 中 。 

Sender : hello Sun Sep 25 11:06:11 CST 2016 

e 切 换 到 应 用 主 类 的 控制 台 ， 我 们 可 以 看 到 类 似 如 下 的 输出 ， 消 费 者 
对 hello 队 列 的 监听 程序 执行 了 ， 并 输出 了 接收 到 的 消息 信息 。 

Receiver : hello Sun Sep 25 11:06:11 CST 2016 

通过 上 面 的 示例 ， 我 们 在 Spring ”Boot 应 用 中 引入 spring-boot-starter- 
amqp 模 块 ， 进 行 简 单 配置 就 完成 了 对 RabbitMQ 的 消息 生产 和 消费 的 开 
发 内 容 。 然 而 在 实际 应 用 中 ， 还 有 很 多 内 容 没 有 演示 ， 比 如 之 前 提 到 的 
一 些 概念 : 交换 机 、 路 由 关键 字 、 绑 定 、 虚 拟 主机 等 ， 这 里 不 做 更 多 的 
讲解 ， 读 者 可 以 自行 查阅 ”RabbitMQ ”的 官方 教程 ， 其 中 有 更 全 面 的 讲 
解 。 在 这 里 ， 我 们 需要 重点 理解 的 是 ， 在 整个 生产 消费 过 程 中 ， 生 产 和 
消费 是 一 个 异步 操作 ， 这 也 是 在 分 布 式 系统 中 要 使 用 消息 代理 的 重要 原 
因 ， 以 此 我 们 可 以 使 用 通信 来 解 契 业 务 逻 辑 。 在 这 个 例子 中 ， 读 者 可 以 
进一步 做 一 些 测试 ， 比 如 ， 不 运行 消费 者 ， 先 运行 生产 者 ， 此 时 可 以 看 
到 在 RabbitMQ ”Server 省 理 页 面 的 Queues 选 项 卡 下 多 了 一 些 竺 处理 的 消 
思 ， 这 时 我 们 再 启动 消费 者 ， 它 就 会 处 理 这 些 消息 ， 所 以 通过 生产 消费 
模式 的 异步 操作 ， 系 统 间 调用 就 没有 同步 调用 需要 那么 高 的 实时 性 要 
求 ， 同 时 也 更 容易 控制 处 理 的 吞吐 量 以 保证 系统 的 正常 运行 等 。 

在 上 一 节 中 ， 我 们 已 经 介绍 了 关于 消息 代理 、AMQP 以 及 RabbitMQ 
的 基础 知识 和 使 用 方法 。 在 下 面 的 内 容 中 ， 我 们 开始 具体 介绍 Spring 
Cloud Bus 的 配置 ， 并 以 一 个 Spring Cloud Bus 与 Spring Cloud Config 结 合 








的 例子 来 实现 配置 内 容 的 实时 更 新 。 

先 回 顾 一 下 ， 在 上 一 章 Spring Cloud Config 的 介绍 中 ， 我 们 留 了 一 个 
巧 念 : 如 何 实现 对 配置 信息 的 实时 更 新 。 虽 然 我 们 已 经 能 够 通过 /refresh 
接口 和 Git 仓库 的 Web Hook 来 实现 Git 仓库 中 的 内 容 修改 触发 应 用 程序 
的 属性 更 新 。 但 是 ， 徊 所 有 触发 操作 均 需 要 我 们 手工 去 维护 Web Hook 
中 的 应 用 配置 的 话 ， 随 着 系统 的 不 断 扩展 ， 会 变 得 越 来 越 难 以 维护 ， 而 
消息 代理 中 间 件 是 解决 该 问题 最 为 合适 的 方案 。 是 否 还 记得 我 们 在 介绍 
消 妃 代理 中 的 特点 时 提 到 过 这 样 一 个 功能 : 消 妃 代理 中 间 件 可 以 将 消 妃 
路 由 到 一 个 或 多 个 目的 地 。 利 用 这 个 功能 ， 我 们 就 能 完美 地 解决 该 问 
题 ， 下 面 来 说 说 Spring Cloud Bus 中 的 具体 实现 方案 。 











整合 Spring Cloud Bus 


为 Spring Cloud 基于 Spring Boot， 在 上 一 节 中 我 们 已 经 体验 了 
Spring ”Boot 与 RabbitMQ 的 整合 ， 所 以 在 Spring ” Cloud Bus 中 使 用 
RabbitMQ 也 是 非常 容易 配置 的 。 

下 面 我 们 来 具体 动手 尝试 整个 配置 过 程 。 

e; 准 备 工作 : 这 里 我 们 不 创建 新 的 应 用 ， 但 需要 用 到 上 一 章 中 已 经 实 
现 的 关于 Spring Cloud Config 的 几 个 工程 ， 知 读者 对 其 还 不 了 解 ， 建 议 
先 阅读 第 8 章 的 内 容 。 

加 config-repo: 定义 在 Git 仓 库 中 的 一 个 目录 ， 其 中 存储 了 应 用 名 为 
didispace 的 多 环境 配置 文件 ， 配 置 文件 中 有 一 个 from 人 参数 。 

加 config-server-eureka: 配置 了 Git 仓 库 ， 并 注册 到 了 Eureka 的 服务 
端 。 

加 config-client-eureka: 通过 Eureka 发 现 Config Server 的 客户 端 ， 应 用 
名 为 didispace， 用 来 访问 配置 服务 器 以 获取 配置 信息 。 该 应 用 中 提供 了 
一 个 /from 接口 ， 它 会 获取 config-repo/didispace-dev.properties 中 的 from 
属性 并 返回 。 

e@ 扩 展 config-client-eureka 应 用 。 

四 修改 pom.xml， 增 加 spring-cloud-starter-bus-amqp 模 块 〈 注 意 
springboot-starter-actuator 模 块 也 是 必需 的 ， 用 来 提供 刷新 端点 〉。 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-bus-amqp</artifactId> 

</dependency> 

e 在 配置 文件 中 增加 关于 RabbitMQ 的 连接 和 用 户 信息 。 

Spring.rabbitmq.host=localhost 




















Spring.rabbitmq.port=5672 

Spring.rabbitmq.username=springcloud 

spring.rabbitmq.password=123456 

e 局 动 config-server-eureka， 再 局 动 两 个 config-client-eureka (分 别 在 
不 同 的 端口 上 ， 比 如 7002、7003) 。 我 们 可 以 在 config-client-eureka 中 的 
台中 看 到 如 下 内 容 ， 在 启动 时 ， 客 户 端 程序 多 了 一 个 /bus/refresh 请 





0.s.b.a.e.mvc.EndpointHandlerMapping : Mapped 

"{[/bus/refresh],methods=[POST]}" onto public void 

org.springframework.cloud.bus.endpoint.RefreshBusEndpoint.refresh (ja 

e 先 访问 两 个 ”config-client-eureka ”的 /from ”请求 ， 会 返回 当前 
configrepo/didispace-dev.properties 中 的 from 属 性 。 

e 接 着 ， 修 改 config-repo/didispace-dev.properties 中 的 from 属 性 值 ， 并 
发 送 POST 请 求 到 其 中 的 一 个 /bus/refresh。 

ee 最后， 再 分 别 访问 启动 的 两 个 config-client-eureka 的 /from 请 求 ， 此 
时 这 两 个 请 求 都 会 返回 最 新 的 config-repo/didispace-dev.properties 中 的 
from 属 性 。 

到 这 里 ， 我 们 已 经 能 够 通过 Spring Cloud Bus 来 实时 更 新 总 线 上 的 属 

性 配置 了 。 


于 2 


上 一 节 中 ， 我 们 通过 使 用 Spring Cloud Bus 与 Spring Cloud Config 的 
整合 ， 并 以 RabbitMQ 作 为 消息 代理 ， 实 现 了 应 用 配置 的 动态 更 新 。 

整个 方案 的 架构 如 下 图 所 示 ， 其 中 包含 了 Git 仓 库 、Config Server 以 
及 几 个 微服 务 应 用 的 实例 ， 这 些微 服务 应 用 的 实例 中 都 引入 了 ”Spring 
Cloud Bus， 所 以 它们 都 连接 到 了 RabbitMQ 的 消息 总 线 上 。 


当 我 们 将 系统 局 动 起 来 之 后 ， 图 中 “Service A” 的 三 个 实例 会 请 求 
Config Server 以 获取 配置 信息 ，Config Server 根 据 应 用 配置 的 规则 从 Git 
仓库 中 获取 配置 信息 并 返回 。 

此 时 ， 若 我 们 需要 修改 “Service A” 的 属性 。 首 先 ， 通 过 Git 管 理工 具 
去 仓库 中 修改 对 应 的 属性 值 ， 但 是 这 A” 实 例 
的 属性 更 新 。 我 们 同 “Service A” 的 实例 3 发 送 POST 请 求 ， 访 
问 /bus/refresh 接 口 。 些 时， “Service A” 的 实例 3 就 会 将 刷新 请 求 发 送 到 消 
息 总 线 中 ， 该 消息 事件 会 被 “Service A” 的 实例 1 和 实例 2 从 总 线 中 获取 
到 ， 并 重新 从 Config Server 中 获取 它们 的 配置 信息 ， 从 而 实现 配置 信息 





的 动态 更 新 。 

而 从 Git 仓 库 中 配置 的 修改 到 发 起 /bus/refresh 的 POST 请 求 这 一 步 可 以 
通过 Git 仓 库 的 Web Hook 来 自动 触发 。 由 于 所 有 连接 到 消息 总 线 上 的 应 
用 都 会 接收 到 更 新 请 求 ， 所 以 在 Web Hook 中 就 不 需要 维护 所 有 节点 内 
0 从 而 解决 了 上 一 章 中 仅 通 过 Web Hook 来 逐个 进行 刷新 

问题 。 





在 上 面 的 例子 中 ， 我 们 通过 加 服务 实例 请 求 Spring Cloud Bus 
的 /bus/refresh 接 口 ， 从 而 触发 总 线 上 其 他 服务 实例 的 /refresh。 但 是 在 一 
些 特殊 场景 下 ， 我 们 希望 可 以 刷新 微服 务 中 某 个 具体 实例 的 配置 。 

Spring Cloud Bus 对 这 种 场景 也 有 很 好 的 文 持 ，/busrefresh 接口 提供 
了 一 个 destination 参数 ， 用 来 定位 具体 要 刷新 的 应 用 程序 。 比 如 ， 我 们 
可 以 请 求 /bus/refresh? destination=customers:9000， 此 时 总 线 上 的 各 应 用 
实例 会 根据 destination 属性 的 值 来 判断 是 否 为 上 自己 的 实例 名 ， 知 符合 才 
进行 配置 刷新 ， 大 不 符合 就 忽略 该 消息 。 

关于 应 用 的 实例 名 ， 我 们 在 之 前 介绍 Spring Cloud Netflix 的 Eureka 时 
有 过 详细 的 介绍 ， 它 的 默认 命名 按 此 规则 生成 : 
${spring.cloud.client.hostname}:${spring.application.name}:${spring.applica 
想 了 解 更 多 内 容 可 查看 第 3 章 的 相关 介绍 。 

destination 参数 除了 可 以 定位 具体 的 实例 之 外 ， 还 可 以 用 来 定位 具体 
的 服务 。 定 位 服务 的 原理 是 通过 使 用 Spring 的 PathMatecher (路 人 径 区 
配 ) 来 实现 的 ， 比 如 /bus/refresh? destination=customers:**， 该 请 求 会 触 
发 customers 服 务 的 所 有 实例 进行 刷新 。 


架构 优化 


既然 Spring Cloud Bus 的 /bus/refresh 接 口 提供 了 针对 服务 和 实例 进行 
配置 更 新 的 参数 ， 那 么 我 们 的 架构 也 可 以 相应 做 出 一 些 调整 。 在 之 前 的 
架构 中 ， 服 务 的 配置 更 新 需要 通过 向 具体 服务 中 的 某 个 实例 发 送 请 求 ， 
再 触发 对 整个 服务 集群 的 配置 更 新 。 虽 然 能 实现 功能 ， 但 是 这 样 的 结果 
是 ， 我 们 指定 的 应 用 实例 会 不 同 于 集群 中 的 其 他 应 用 实例 ， 这 样 会 增加 
集群 内 部 的 复杂 度 ， 不 利于 将 来 的 运 维 工作 。 比 如 ， 需 要 对 服务 实例 进 
行 迁移 ， 那 么 我 们 不 得 不 修改 Web Hook 中 的 配置 等 。 所 以 要 尽 可 能 地 
让 服务 集群 中 的 各 个 节点 是 对 等 的 。 

因此 ， 我 们 将 之 前 的 架构 做 了 一 些 调整 ， 如 下 图 所 示 。 








我 们 主要 做 了 以 下 这 些 改动 : 

1. 在 Config Server 中 也 引入 Spring Cloud Bus， 将 配置 服务 端 也 加 入 到 
消息 总 线 中 来 。 

2./bus/refresh 请 求 不 再 发 送 到 具体 服务 实例 上 ， 而 是 发 送 给 Config 
Server， 并 通过 destination 参 数 来 指定 需要 更 新 配置 的 服务 或 实例 。 

通过 上 面 的 改动 ， 我 们 的 服务 实例 不 需要 再 承担 触发 配置 更 新 的 职 
贡 。 同 时 ， 对 于 Git 的 触发 等 配置 都 只 需要 针对 Config Server 即 可 ， 从 而 
简化 了 集群 上 的 一 些 维护 工作 。 





RabbitMQ 配 首 
Spring Cloud Bus 中 的 RabbitMQ 整 合 使 用 了 Spring Boot 的 
ConnectionFactory， 上 所 以 在 Spring Cloud Bus 中 支持 使 用 以 


spring.rabbit.mdq 为 前 缀 的 Spring ” Boot 配置 属性 ， 具 体 的 配置 属性 、 说 明 
以 及 默认 值 如 下 表 所 示 。 


续 表 


Kafka 实 现 消 息 总 线 


Spring Cloud Bus 除了 支持 RabbitMQ 的 自动 化 配置 之 外 ， 还 支持 现 
在 被 广泛 应 用 的 Kafka。 在 本 节 中 ， 我 们 将 搭建 一 个 Kafka 的 本 地 环境 ， 


Kafka 倍 介 


Kafka 是 一 个 由 LinkedIn 开 发 的 分 布 式 消息 系统 ， 它 于 2011 年 年 初 开 
源 ， 现 在 由 著名 的 Apache 基 金 会 维护 与 开发 。Kafka 使 用 Scala 实 现 ， 被 
用 作 LinkedIn 的 活动 流 和 运营 数据 处 理 的 管道 ， 现 在 也 被 诸多 互联 网 企 
业 广 泛 地 用 作 数 据 流 管道 和 消息 系统 。 

Kafka 是 基于 消息 发 布 -订阅 模式 实现 的 消息 系统 ， 其 主要 设计 目标 
如 下 所 述 。 

e 消 息 持 久 化 : 以 时 间 复 杂 度 为 O (1) 的 方式 提供 消息 持久 化 能 
力 ， 即 使 对 TB 级 以 上 的 数据 也 能 保证 常数 时 间 复 杂 度 的 访问 性 能 。 

e 高 硅 吐 : 在 廉价 的 商用 机 器 上 也 能 支持 单机 每 秒 10 万 条 以 上 的 吞 吐 


e 分 布 式 : 文 持 消 息 分 区 以 及 分 布 式 消费 ， 并 保证 分 区 内 的 请 恩 顺 
e 跨 平台 : 文 持 不 同 技术 平台 的 客户 并 (如 Java、PHP、Python 


e 实 时 性 : 文 持 实时 数据 处 理 和 离线 数据 处 理 。 
e 伸 缩 性 : 文 持 水 平 扩展 。 
Kafka 中 涉及 的 一 些 基 本 概念 ， 如 下 所 示 。 
eBroker:Kafka 集 群 包含 一 个 或 多 个 服务 器 ， 这 些 服 务 嚣 被 称 大 
Broker。 
eTopic: 逻辑 上 同 RabbitMQ 的 Queue 队 列 相 似 ， 每 条 发 布 到 Kafka 集 
群 的 消息 都 必须 有 一 个 Topic。 “物理 上 不 同 Topic 的 消息 分 开 存储 ， 逮 
辑 上 一 个 Topic 的 消息 虽然 保存 于 一 个 或 多 个 Broker 上 ， 但 用 户 只 需 指定 
消息 的 Topic 即 可 生产 或 消费 数据 而 不 必 关 心 数据 存 于 何 处 。) 
ePartition:Partition 是 物理 概念 上 的 分 区 ， 为 了 提供 系统 吞吐 率 ， 在 
物理 上 每 个 Topic 会 分 成 一 个 或 多 个 Partition， 每 个 Partition 对 应 一 个 文 
件 夹 (存储 对 应 分 区 的 消息 内 容 和 索引 文件 〉。 
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eProducer: 消息 生产 者 ， 负 责 生 产 消 息 并 发 送 到 Kafka Broker。 

eConsumer: 消息 消费 者 ， 向 Kafka ”Broker 读 取消 息 并 处 理 的 客户 
端 。 

eConsumer Group: 每 个 Consumer 属 于 一 个 特定 的 组 (可 为 每 个 
Consumer 指 定 属于 一 个 组 ， 知 不 指定 则 属于 默认 组 ) ， 组 可 以 用 来 实现 
一 条 消息 被 组 内 多 个 成 员 消 费 等 功能 。 
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在 对 Kafka 有 了 一 些 基本 了 解 之 后 ， 下 面 我 们 来 尝试 搭建 一 个 Kafka 
服务 端 ， 并 体验 一 下 基于 Kafka 的 消息 生产 与 消费 。 

环境 安 闭 

首先 ， 我 们 需要 从 官网 上 下 载 安 装 介 质 。 下 载 地 址 为 
http:/kafka.apache.org/downloads.html。 本 例 中 采用 的 版 本 为 Kafka- 
0.10.0.1。 

在 解压 Kafka 的 安装 包 之 后 ， 可 以 看 到 其 目录 结构 如 下 所 示 : 

kafka 

+-bin 

+-windows 

+-config 

+-libs 

+-logs 

+-site-docs 

由 于 Kafka 的 设计 中 依赖 了 ZooKeeper， 所 以 我 们 在 bin 和 config 目 录 
中 除了 看 到 Kafka 相关 的 内 容 之 外 ， 还 有 ZooKeeper 相关 的 内 容 。 其 中 
bin 目录 中 存放 了 Kafka 和 ZooKeeper 的 命令 行 工 具 ，bin 根 目录 下 存放 
的 是 适用 于 Linux/UNIX 的 shell， 而 bin/windows 下 存放 的 则 是 适用 于 
Windows 下 的 bat。 我 们 可 以 根据 实际 的 系统 来 设置 环境 变量 ， 以 方便 后 
和 操作 。 而 config 目 录 ， 则 用 来 存放 关于 Kafka 与 ZooKeeper 的 
配置 信息 。 

启动 测试 

下 面 我 们 来 尝试 启动 ZooKeeper 和 Kafka 来 进行 消息 的 生产 和 消费 。 
示例 中 所 有 的 命令 均 以 配置 了 Kafka 的 环境 变量 为 例 。 

@ 启 动 ZooKeeper， 执 行 命令 Zookeeper-server-start 
config/zookeeper.properties， 该 命令 需要 指定 ZooKeeper 的 配置 文件 位 置 
才能 正确 启动 ，Kafka 的 压缩 包 中 包含 了 其 默认 配置 ， 开 发 与 测试 环境 
基本 不 需要 修改 ， 所 以 这 里 不 做 详细 介绍 ， 对 于 线 上 的 调 优 需求 ， 请 读 














者 自行 查看 官方 文档 进行 操作 。 

[2016-09-28 08:05:34,849]INFO Reading configuration from: 
config\zookeeper. 

properties (org.apache.zookeeper.server.guorum.QuorumPeerConfig) 

[2016-09-28 08:05:34,850]INFO autopurge.snapRetainCount set to 
3 (org.apache. 

zookeeper.server.DatadirCleanupManager) 

[2016-09-28 08:05:34,851]INFO autopurge.purgelnterval set to 
0 (org.apache. 

zookeeper.server.DatadirCleanupManager) 

[2016-09-28 08:05:34,851]INFO Purge task is not scheduled. 
(org.apache.zookeeper. 

server.DatadirCleanupManager) 

[2016-09-28 08:05:34,852]WARN Either no config or no quorum defined 
in config, 

running in standalone 
mode (org.apache.zookeeper.server.qguorum.QuorumPeerMain) 

[2016-09-28 08:05:34,868]INFO Reading configuration from: 





config\zookeeper. 
properties (org.apache.zookeeper.server.guorum.QuorumPeerConfig) 
[2016-09-28 08:05:34,869]INFO Starting 
server (org.apache.zookeeper.server. 
ZooKeeperServerMain) 
[2016-09-28 08:05:34,940]INFO binding to port 


0.0.0.0/0.0.0.0:2181 (org.apache. 
zookeeper.server.NIOServerCnxnFactory) 

从 控制 台 信 息 中 我 们 可 以 看 到 ，ZooKeeper 从 指定 的 
config/zookeeper.properties ”配置 文件 中 读 取 信息 并 绑 定 2181 端 口 司 动 服 
务 。 有 时候 启 动 失败 ， 可 但 看 一 下 端口 是 否 被 占用 ， 可 以 杀 掉 占用 进程 
或 通过 修改 config/zookeeper.properties 配 置 文件 中 的 clientPort 内 容 以 绑 定 
其 他 端口 号 来 启动 ZooKeeper。 

e 启 动 Kafka， 执 行 命令 kafka-server-start config/server.properties， 该 
命令 也 需要 指定 Kafka 配 置 文件 的 正确 位 置 ， 如 上 命令 中 指 癌 了 解压 目 
录 包 含 的 默认 配置 。 寿 在 测试 时 ， 使 用 外 部 集中 环境 的 ZooKeeper 的 
话 ， 我 们 可 以 在 该 配置 文件 中 通过 zookeeper.connect 参 数 来 设置 
ZooKeeper 的 地 址 和 端口 ， 它 默认 会 连接 本 地 2181 问 口 的 ZooKeeper; 如 


果 需 要 设置 多 个 ZooKeeper 节 点 ， 可 以 为 这 个 参数 配置 多 个 ZooKeeper 
地 址 ， 并 用 逗号 分 阳 。 比 如 
Zookeeper.cConnect=127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002。 除 此 之 
外 ， 该 配置 文件 中 还 提供 了 关于 服务 端 连接 、 日 志 等 配置 参数 ， 具 体 的 
线 上 配置 可 根据 实际 情况 进行 调整 。 

e 创 建 Topic， 执 行 命令 kafka-topics--create--Zzookeeper localhost:2181-- 
replication-factor 1--partitions 1--topic test。 通 过 该 命令 ， 创 建 了 一 个 名 为 
test 的 Topic， 该 Topic 包 含 一 个 分 区 和 一 个 Replica。 在 创建 完成 后 ， 可 以 
使 用 kafka-topics--list--zookeeper localhost:2181 命 令 来 查看 当前 的 Topic。 

另外 ， 如 果 不 使 用 kafka-topics 命令 来 手工 创建 ， 直 接 使 用 下 面 的 内 
容 进行 消息 创建 时 也 会 自动 创建 Topics。 

e 创 建 消 恩 生产 者 ， 执 行 命令 kafka-console-producer--broker-list 
localhost:9092--topic test。kafka-console-producer 命令 可 以 局 动 Kafka 基 
于 命令 行 的 消息 生产 客户 端 ， 局 动 后 可 以 直接 在 控制 台中 输入 消 县 来 有 
送 ， 控 制 台中 的 每 一 行 数据 都 会 被 视 为 一 条 消息 来 有 发送。 我 们 可 以 符 试 
输入 几 行 消息 ， 由 于 此 时 并 没有 消费 者 ， 所 以 这 些 输 入 的 消 上 县 都 会 被 阻 
塞 在 名 为 test 的 Topics 中 ， 直 到 有 消费 者 将 其 消费 抒 。 

e 创 建 消 恩 消费 者 ， 执 行 命令 kafka-console-consumer--zookeeper 
localhost:2181--topic test--from-beginning。 kafka-consoleconsumer 命 令 启 
动 的 是 Kafka 基 于 命令 行 的 消息 消费 客户 端 ， 局 动 之 后 ， 马 上 可 以 在 控 
制 侣 中 看 到 得 出 了 之 前 我 们 在 消息 生产 客户 端 中 发 送 的 消息 。 我 们 可 以 
再 次 打开 之 前 的 消息 生产 客户 端 来 发 送 消 恩 ， 并 观 聚 消费 者 这 边 对 消 居 
的 输出 来 体验 Kafka 对 消息 的 基础 处 理 。 
































整合 Spring Cloud Bus 


在 介绍 Kafka 之 前 ， 我 们 已 经 通过 引入 spring-cloud-starter-bus-amqp 模 
块 ， 完 成 了 使 用 RabbitMQ 来 实现 消息 总 线 。 若 我 们 要 使 用 Kafka 来 实 
现 消息 总 线 时 ， 只 需 把 spring-cloud-starter-bus-amqp 蔡 换 成 Spring-cloud- 
starter-bus-kafka 模 块 ， 在 pom.xml 的 dependency 节 点 中 进行 修改 ， 有 具体 如 
下 : 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-bus-kafka</artifactId> 

</dependency> 

如 果 在 启动 Kafka 时 均 采 用 了 默认 配置 ， 那 么 我 们 不 需要 再 做 任何 
其 他 配置 就 能 在 本 地 实现 从 RabbitMQ 到 Kafka 的 切换 。 可 以 尝试 把 刚刚 


搭建 的 ZooKeeper、Kafka 启 动 起 来 ， 并 将 修改 为 spring-cloud-starter-bus- 
kafka 模块 的 config-server 和 config-client 局 动 起 来 。 
在 config-server 局 动 时 ， 我 们 可 以 在 控制 台中 看 到 如 下 输出 : 


从 控制 台 的 输出 内 容 我 们 可 以 看 到 ，config-server 连 接 到 了 Kafka 
中 ， 并 使 用 了 名 为 springCloudBus 的 Topic。 

此 时 ， 我 们 可 以 使 用 kafka-topics--list--zookeeper localhost:2181 命 令 
来 查看 当前 Kafka 中 的 Topic。 寿 已 成 功 启 动 了 config-server 并 配置 正确 ， 
可 以 在 Kafka 中 看 到 已 经 多 了 一 个 名 为 springCloudBus 的 Topic。 

我 们 再 启动 配置 了 spring-cloud-starter-bus-kafka 模 块 的 config-client， 

可 以 看 到 控制 台中 输出 了 如 下 内 容 : 


可 以 看 到 ，config-client 启动 时 输出 了 类 似 的 内 容 ， 它 们 都 订阅 了 名 
为 SpringCloudBus 的 Topic。 从 这 里 我 们 也 可 以 知道 ， 在 消息 总 线 上 的 节 
点 ， 从 结构 上 来 说 ， 不 论 是 config-server 还 是 config-client， 它 们 都 是 对 
全 大 

在 启动 了 config-server 和 config-client 之 后 ， 为 了 更 明显 地 观察 消息 总 
线 刷新 配置 的 效果 ， 我 们 可 以 在 本 地 启动 多 个 不 同 端口 的 config- 
dlient。 此 时 ， 我 们 的 config-server 以 及 多 个 config-client 都 已 经 连接 到 
了 由 ”Kafka 实现 的 消息 总 线 上 。 我 们 可 以 先 访问 各 个 config-client 上 
的 /from 请 求 ， 碍 看 它 获 取 到 的 配置 内 容 。 然 后 ， 修 改 Git 中 对 应 的 参数 
内 容 ， 再 访问 各 个 config-client 上 的 /from 请 求 ， 可 以 看 到 配置 内 容 并 没 
有 改变 。 最 后 ， 我 们 向 config-server 发 送 POST 请 求 : /bus/refresh， 此 
时 再 去 访问 各 个 config-client 上 的 /from 请 求 ， 束 能 获得 最 新 的 配置 信 
晨 ， 各 客户 端 上 的 配置 都 已 经 加 载 为 最 新 的 Git 配 置 内 容 。 

从 config-client 的 控制 台中 ， 我 们 可 以 看 到 如 下 内 容 : 

2016-09-29 08:20:34.361 INFO 21256---[kafka-binder-1] 

0.s.cloud.bus.event.RefreshListener : Received remote refresh 
request.Keys 

refreshed[from | 

RefreshListener 监 听 类 记录 了 收 到 远程 刷新 请 
的 日 志 ， 在 下 一 节 中 ， 我 们 将 根据 消息 内 容 与 日 
探索 Spring Cloud Bus 的 工作 机 制 。 


Kafka 配 置 
在 上 面 的 例子 中 ， 由 于 Kafka、ZooKeeper 均 运行 于 本 地 ， 在 自动 化 








求 ， 并 刷新 了 from 属 性 
志 输 出 信息 作为 线索 来 





配置 的 支持 下 ， 我 们 没有 在 测试 程序 中 通过 配置 信息 来 指定 Kafka 和 
ZooKeeper 的 配置 信息 ， 束 完成 了 本 地 消 恩 总 线 的 试验 。 但 是 在 实际 应 
用 中 ，Kafka 和 ZooKeeper 一 般 都 会 独立 部 署 ， 所 以 在 应 用 中 需要 为 
Kafka 和 ZooKeeper 配 置 一 些 连接 信息 等 。Kafka 的 整合 与 RabbitMQ 不 

同 ， 在 Spring Boot 1.3.7 中 并 没有 直接 提供 Starter 模 块 ， 而 是 采用 了 
Spring ”Cloud ”Stream 的 Kafka 模块 ， 所 以 对 于 Kafka 的 配置 均 采 用 了 
spring.cloud.stream.kafka 前 级 ， 具 体 的 配置 内 容 我 们 可 以 参考 第 10 章 

的 “ 绑 定 避 配 置 " 一 市 中 关于 Kafka 配 置 的 内 容 。 





在 整合 Kafka 实 现 了 消息 总 线 之 后 ， 我 们 不 妨 继续 使 用 Kafka 提 供 的 
控制 台 消 费 者 来 看 看 ， 当 执行 /bus/refresh 时 ， 消 息 消费 者 都 获得 了 什 
么 。 通 过 前 文 我 们 从 控制 台中 获得 的 信息 可 以 知道 ，Spring Cloud Bus 使 
用 了 名 为 springCloudBus 的 Topic， 上 所 以 我 们 可 以 使 用 命令 kafka-console- 
consumer--zookeeper localhost:2181--topic springCloudBus， 启 动 对 
springCloudBus 的 消费 者 控制 台 来 进行 观察 。 

启动 消费 者 控制 台 之 后 ， 我 们 同 config-server 发 送 POST 请 
求 : /bus/refresh， 此 时 在 控制 台中 可 以 看 到 类 似 如 下 的 内 容 : 

contentType "application/json" 

{ 

"type": "RefreshRemoteApplicationEvent", 

"timestamp": 1475073160814, 

"OriginService": "config-server:7001", 

"destinationService™: "*:**"™ 

"id": "bbfbf495-39d8-4ff9-93d6-174873ff7299" 

1 

contentType "application/json" 

{ 

"type": "AckRemoteApplicationEvent", 

"timestamp": 1475073160821, 

"OriginService": "config-server:7001", 

"destinationService™: "*:**"™ 

"id": "1f794774-10d6-4140-a80d-470983c6c0ff", 

"ackId": "bbfbf495-39d8-4ff9-93d6-174873ff7299", 

"ackDestinationService": "*:**" 

"event": 
"org.springframework.cloud.bus.event.RefreshRemoteApplicationEvent" 

} 

contentType "application/json" 

{ 

"type": "AckRemoteApplicationEvent", 

"timestamp": 1475075467554, 

"originService": "didispace:7002", 

"destinationService™": "*:**"™ 














"id": "7560151e-f60c-49cd-8167-b691e846ad08", 

"ackId": "21502725-28f5-4d19-a98a-f8114fa4fldc", 

"ackDestinationService": "*:**" 

"event": 
"org.springframework.cloud.bus.event.RefreshRemoteApplicationEvent" 


} 


下 面 ， 我 们 来 详细 理解 消 恩 中 的 信息 内 容 。 

etype: 消息 的 事件 类 型 。 在 上 面 的 例子 中 ， 包 含 了 
RefreshRemoteApplicationEvent 和 AckRemoteApplicationEvent。 其 中 ， 
RefreshRemoteApplicationEvent 事 件 就 是 我 们 用 来 刷新 配置 的 事件 ， 而 
AckRemoteApplicationEvent 是 啊 应 消息 已 经 正确 接收 的 告知 消息 事件 。 

etimestamp: 消息 的 时 间 惟 。 

eoriginService: 消息 的 来 源 服 务实 例 。 

edestinationService: 消 恩 的 目标 服务 实例 。 上 面 示例 中 的 *:** 代 表 
了 总 线 上 的 所 有 服务 实例 。 如 果 想 要 指定 服务 或 是 实例 ， 在 之 前 介绍 
RabbitMQ 实现 消息 总 线 时 已 经 提 过 ， 只 需要 通过 使 用 destination 参 数 来 
定位 具体 要 刷新 的 应 用 实例 即 可 ， 比 如 发 起 /bus/refresh? 
destination=didispace 请 求 ， 就 可 以 得 到 如 下 的 刷新 事件 消息 ， 其 中 
destinationService 为 didispace:**， 表 示 总 线 上 所 有 didispace 服 务 的 实 
例 。 

contentType "application/json" 

{ 

"type": "RefreshRemoteApplicationEvent", 

"timestamp": 1475131215007， 

"originService": "config-server:7001", 

"destinationService": "didispace:**", 

"id": "667fe948-e9b2-447f-be22-3c8acf{f647ead" 

















} 

eid: 消息 的 唯一 标识 。 

上 面 的 消息 内 容 是 RefreshRemoteApplicationEvent 和 
AckRemoteApplicationEvent 类 型 共有 的 ， 下 面 几 个 属性 是 
AckRemoteApplicationEvent 所 特有 的 ， 分 别 表示 如 下 含义 。 

eackId:Ack 消 息 对 应 的 消息 来 源 。 我 们 可 以 看 到 第 一 条 
AckRemoteApplicationEvent 的 ackId 对 应 了 
RefreshRemoteApplicationEvent 的 id， 说 明 这 条 Ack 是 告知 该 
RefreshRemoteApplicationEvent 事 件 的 消息 已 经 被 收 到 。 





eackDestinationService:Ack 消息 的 目标 服务 实例 。 可 以 看 到 这 里 使 
用 的 是 *:**， 所 以 消息 总 线 上 所 有 的 实例 都 会 收 到 该 Ack 消 息 。 

eevent:Ack 消息 的 来 源 事件 。 可 以 看 到 上 例 中 的 两 个 Ack 均 来 源 于 
刷新 配置 的 RefreshRemoteApplicationEvent 事件 ， 我 们 在 测试 的 时 候 由 
于 启动 了 两 个 config-client， 所 以 有 两 个 实例 接收 到 了 配置 刷新 事件 ， 同 
时 它们 都 会 返回 一 个 Ack 消 息 。 由 于 ackDestinationService 为 *:**， 所 以 
两 个 config-client 都 会 收 到 对 RefreshRemoteApplicationEvent 事 件 的 Ack 消 
息 。 


Le 











源码 分 析 


通过 上 面 的 分 析 ， 我 们 已 经 得 到 了 两 个 非常 重要 的 线索 
RefreshRemoteApplicationEvent 和 AckRemoteApplicationEvent。 我 们 不 妨 
顺 着 这 两 个 事件 类 来 详细 看 看 Spring Cloud Bus 的 源码 ， 以 帮助 我 们 理解 
它 的 运行 机 制 。 

顺 着 RefreshRemoteApplicationEvent 和 AckRemoteApplicationEvent， 
我 们 可 以 整理 出 如 下 的 事件 关系 类 图 。 


可 以 看 到 ， 其 中 RefreshRemoteApplicationEvent 和 
AckRemoteApplicationEvent 这 些 我 们 已 经 接触 过 的 事件 都 继承 了 
RemoteApplicationEvent 抽象 类 ， 而 RemoteApplicationEvent 继 承 目 
Spring Framework 的 ApplicationEvent， 可 以 断定 ，Spring Cloud Bus 也 采 
用 了 Spring 的 事件 驱动 模型 。 

事件 驱动 模型 

如 果 读 者 对 Spring 的 事件 驱动 模型 已 经 非常 了 解 ， 那 么 可 以 跳 过 这 一 
小 节 ， 直 接 看 后 面 的 分 析 。 如 果 你 还 不 清楚 它 的 原理 ， 建 议 先 通过 本 小 
节 的 内 容 来 理解 其 基本 原理 ， 以 帮助 阅读 和 理解 后 续 的 源码 分 析 内 容 。 

Spring 的 事件 驱动 模型 中 包含 了 三 个 基本 概念 : 事件 、 事 件 监听 者 
和 事件 发 布 者 ， 如 下 图 所 示 。 


e 事 件 : Spring 中 定义 了 事件 的 抽象 类 ApplicationEvent， 它 继承 自 
JDK ”的 EventObject 类 。 从 图 中 我 们 可 以 看 到 ， 事 件 包 含 了 两 个 成 员 变 
量 : timestamp， 该 字段 用 于 存储 事件 发 生 的 时 间 惟 ， 以 及 父 类 中 的 
source， 该 字段 表示 源 事件 对 象 。 当 我 们 需要 自 定义 事件 的 时 候 ， 只 需 
要 继承 ApplicationEvent， 比 如 RemoteApplicationEvent、 
RefreshRemoteApplicationEvent 等 ， 可 以 在 自 定 义 的 Event 中 增加 一 些 事 
件 的 属性 来 给 事件 监听 者 处 理 。 











e 事 件 监听 者 : Spring 中 定义 了 事件 监听 者 的 接口 
ApplicationListener， 它 继承 自 JDK 的 EventListener 接 口 ， 同 时 
ApplicationListener 接 口上 限定 了 ApplicationEvent 子 类 作为 该 接口 中 
onApplicationEvent (E event) ; 函数 的 参数 。 所 以 ， 每 一 个 
ApplicationListener 都 是 针对 某 个 ApplicationEvent 子 类 的 监听 和 处 理 


那么 ， 事 件 与 监听 者 是 如 何 关 联 起 来 的 呢 ? 我 们 看 下 图 ; 


e 事 件 发 布 者 : Spring 中 定义 了 ApplicationEventPublisher 和 
ApplicationEventMulticaster 两 个 接口 用 来 发 布 事件 。 其 中 
ApplicationEventPublisher 接 口 定 义 了 发 布 事件 的 函数 
publishEvent (ApplicationEvent event) 和 publishEvent (Object event) ; 
而 ApplicationEventMnulticaster 接 口中 定义 了 对 ApplicationListener 的 维护 
操作 (比如 新 增 、 移 除 等 ) 以 及 将 ApplicationEvent 多 播 给 可 用 
ApplicationListener 的 操作 。 

ApplicationEventPublisher 的 publishEvent 实现 在 
AbstractApplicationContext 中 ， 有 具体 如 下 : 

protected void publishEvent (Object event,ResolvableType eventType) 








{ 


Assert.notNull (event,"Event must not be null" ) ; 


if (this.earlyApplicationEvents !=null ) { 
this.earlyApplicationEvents.add (applicationEvent) ; 


else { 
getApplicationEventMulticaster () .multicastEvent (applicationEvent,e' 


} 
} J 
可 以 看 到 ， 它 最 终 会 调用 ApplicationEventMulticaster 的 multicastEvent 


来 具体 实现 发 布 事件 给 监听 者 的 操作 。 而 ApplicationEventMulticaster 在 
Spring 的 默认 实现 位 于 SimpleApplicationEventMulticaster 中 ， 具 体 如 下 : 








SimpleApplicationEventMulticaster 通 过 过 历 维护 的 ApplicationListener 
集合 来 找到 对 应 ApplicationEvent 的 监听 器 ， 然 后 调用 监听 器 的 
onApplicationEvent 函 数 来 对 有 具体 事件 做 出 处 理 操作 。 

事件 定义 





在 对 Spring 的 事件 模型 有 了 一 定 的 理解 之 后 ， 下 面 我 们 来 详细 介绍 
Spring Cloud Bus 中 的 事件 定义 。 首 先 ， 从 RemoteApplicationEvent 抽 和 象 
类 开始 : 


先 来 看 看 RemoteApplicationEvent 类 上 修饰 的 注解 。 

eQ@JsonTypelnfo (use=JsonTypelInfo.Id.NAME,property="type") :Jacks 
对 多 态 类 型 的 处 理 注解 ， 当 进行 序列 化 时 ， 会 使 用 子 类 的 名 称 作为 type 
属性 的 值 ， 比 如 之 前 示例 中 的 "type": "RefreshRemoteApplicationEvent"。 

e@JsonIgnoreProperties ("source") : 序列 化 的 时 候 忽 略 source 属 
性 ，source 是 ApplicationEvent 的 父 类 EventObject 的 属性 ， 用 来 定义 事件 
的 发 生源 。 

再 来 看 看 它 的 属性 : originService、destinationService、id， 这 些 内 容 
都 可 以 在 RemoteApplicationEvent 的 子 类 事件 消息 中 找到 ， 比 如 : 

{ 

"type": "RefreshRemoteApplicationEvent", 

oD 1475073160814, 

"OriginService": "config-server:7001", 

"destinationService™: "*:**"™ 

"id": "bbfbf495-39d8-4ff9-93d6-174873ff7299" 

} 

| 

"type": "AckRemoteApplicationEvent ， 

"timestamp": 1475075467554， 

"originService": "didispace:7002", 

"destinationService™: "*:**"™ 

"id": "7560151e-f60c-49cd-8167-b691e846ad08", 

"ackId": "21502725-28f5-4d19-a98a-f8114fa4fldc", 

"ackDestinationService": "*:**" 

"event": 
人 springframework.cloud.bus.event.RefreshRemoteApplicationEvent" 








面 ， 我 们 再 来 分 别 看 看 RemoteApplicationEvent 的 几 个 具体 实现 的 
事件 类 。 

SR Rom plea nl Ven 事件 类 ， 该 事件 用 于 远程 刷新 应 用 
的 配置 信息 。 它 的 实现 非常 简单 ， 只 是 继承 了 emote pn on ont 
并 没有 增加 其 他 内 容 。 从 之 前 的 示例 中 我 们 也 能 看 到 ， 消 息 中 的 内 容 与 
RemoteApplicationEvent 中 包含 的 属性 完全 一 致 。 





@SuppressWarnings ("serial") 

public class RefreshRemoteApplicationEvent extends 
RemoteApplicationEvent { 

@SuppressWarnings ("unused") 

private RefreshRemoteApplicationEvent () { 

//for serializers 

} 

public RefreshRemoteApplicationEvent (Object source, String 
originService, 

String destinationService) { 

super (source,originService,destinationService) ; 

} 

} 

eAckRemoteApplicationEvent 事 件 类 ， 该 事件 用 于 告知 某 个 事件 消息 
已 经 被 接收 ， 通 过 该 消息 我 们 可 以 监控 各 个 事件 消息 的 响应 。 从 其 成 员 
属性 中 ， 我 们 可 以 找到 之 前 示例 中 所 总 结 的 ， 比 
RefreshRemoteApplicationEvent 事 件 的 消息 多 出 的 几 个 属性 : ackId、 
ackDestinationService 以 及 event。 其 中 event 成 员 变 量 通 过 泛 型 限定 了 必 
须 为 RemoteApplicationEvent 的 子 类 对 象 ， 该 定义 符合 这 样 的 逻辑 : Ack 
消 恩 衣 定 有 一 个 事件 源头 ， 而 每 一 个 事件 都 必须 继承 
RemoteApplicationEvent 抽 象 类 ， 上 所 以 AckRemoteApplicationEvent 的 事件 
源头 肯定 是 一 个 RemoteApplicationEvent 的 子 类 ， 比 如 示例 中 的 Ack 消 息 
源头 就 是 RemoteApplicationEvent 的 子 类 事件 : 
RefreshRemoteApplicationEvent。 

@SuppressWarnings ("serial") 

public class AckRemoteApplicationEvent extends 
RemoteApplicationEvent { 

private final String ackId; 

private final String ackDestinationService; 

private final Class<? extends RemoteApplicationEvent> event; 

@SuppressWarnings ("unused") 

private AckRemoteApplicationEvent () { 

super () ; 

this.ackDestinationService=null; 

this.ackId=null; 

this.event=null; 


} 

















public AckRemoteApplicationEvent (Object source,String originService, 

String destinationService, String ackDestinationService, String ackId， 

Class<? extends RemoteApplicationEvent> type) { 

super (source,originService,destinationService) ; 

this.ackDestinationService=ackDestinationService; 

this.ackId=ackId; 

this.event=type; 

} 

} 

eEnvironmentChangeRemoteApplicationEvent 事件 类 ， 访 事件 用 于 动 
态 更 新 消息 总 线 上 每 个 节点 的 Spring 环境 属性 。 可 以 看 到 ， 该 类 中 定义 
了 一 个 Map 类 型 的 成 员 变 量 ， 而 接收 消 奶 的 节点 束 是 根据 该 Map 对 象 中 
的 属性 来 覆盖 本 地 的 Spring 环境 属性 。 

@SuppressWarnings ("serial") 

public class EnvironmentChangeRemoteApplicationEvent extends 

RemoteApplicationEvent { 

private final Map<String, String> values; 

@SuppressWarnings ("unused") 

private EnvironmentChangeRemoteApplicationEvent () { 

//for serializers 

values=null; 

} 

public EnvironmentChangeRemoteApplicationEvent (Object 
source, String originService, 

String destinationService, Map<String, String> values) { 

super (source,originService,destinationService) ; 

this.values=values; 


} 








} 

eSentApplicationEvent 事 件 类 ， 细 心 的 读者 可 能 已 经 发 现 ， 访 类 的 结 
构 和 内 容 与 RemoteApplicationEvent 非常 相似 ， 不 同 的 是 : 该 类 不 是 抽 
象 类 ， 并 且 多 一 个 成 员 Class<? extends RemoteApplicationEvent> type。 
SentApplicationEvent 事件 较为 特殊 ， 它 主要 用 于 发 送信 号 来 表示 一 个 远 
程 的 事件 已 经 在 系统 中 被 发 送 到 某 些 地 方 了 ， 从 它 的 继承 关系 中 ， 我 们 
可 以 知道 它 本 喘 并 不 是 一 个 远程 的 事件 〈 不 是 继承 自 











RemoteApplicationEvent) ， 所 以 它 不 会 被 发 送 到 消息 总 线 上 去 ， 而 是 在 
本 地 产生 (通常 是 由 于 响应 了 某 个 远程 的 事件 ) 。 由 于 该 事件 的 id 属 
性 能 够 匹配 消费 者 AckRemoteApplicationEvent 消息 中 的 ackId， 所 以 应 
用 程序 可 以 通过 监听 这 个 事件 来 监控 远程 事件 消息 的 消费 情况 。 

@SuppressWarnings ("serial") 

@JsonTypeInfo (use=JsonTypelInfo.Id.NAME,property="type") 

@JsonIgnoreProperties ("source") 

public class SentApplicationEvent extends ApplicationEvent { 

private static final Object TRANSIENT_ SOURCE=new Object〈) ; 

private final String originService; 

private final String destinationService; 

private final String id; 

private Class<? extends RemoteApplicationEvent> type; 

protected SentApplicationEvent () { 

//for serialization libs like jackson 

this (TRANSIENT_SOURCE,null,null,null,RemoteApplicationEvent.cla 

} 

public SentApplicationEvent (Object source,String originService, 

String destinationService, String id, 

Class<? extends RemoteApplicationEvent> type) { 

super (source) ; 

this.originService=originService; 

this.type=type; 

if (destinationService==null) { 

destinationService="*", 

} 

if (! destinationService.contains (":") ) { 

//All instances of the destination unless specifically requested 

destinationService=destinationServicet+":**¥", 

} 

this.destinationService=destinationService; 

this.id=id; 

} 











} 
事件 监听 器 
在 了 解 了 Spring Cloud Bus 中 的 事件 类 之 后 ， 我 们 来 看 看 另外 一 个 重 





要 元 素 : 事件 监听 右 。 通 过 整理 源码 ， 可 以 得 到 下 面 的 类 图 关系 。 


其 中 ，RefreshListener 和 EnvironmentChangeListener 都 继承 了 Spring 事 
件 模型 中 的 监听 器 接口 ApplicationListener。 我 们 先 来 看 看 
RefreshListener: 

public class RefreshListener 

implements ApplicationListener<RefreshRemoteApplicationEvent> { 

private static Log log=LogFactory.getLog (RefreshListener.class) ; 

private ContextRefresher contextRefresher; 

public RefreshListener (ContextRefresher contextRefresher) { 

this.contextRefresher=contextRefresher:; 

} 

(DOverride 

public void onApplicationEvent (RefreshRemoteApplicationEvent 
event) { 

Set<String> keys=contextRefresher.refresh (); 

log.info ("Received remote refresh request.Keys refreshed "+keys) ; 


} 


} 

从 泛 型 中 我 们 可 以 看 到 该 监听 器 就 是 针对 我 们 之 前 所 介绍 的 
RefreshRemoteApplicationEvent 事件 的 ， 其 中 onApplicationEvent 函数 中 
调用 了 ContextRefresher 中 的 refresh() 函数 进行 配置 属性 的 刷新 。 


public class ContextRefresher { 
private Configurable ApplicationContext context; 


public synchronized Set<String> refresh () { 

Map<String,Object> before=extract ( 

this.context.getEnvironment () .getPropertySources () ) ; 
addConfigFilesToEnvironment () ; 

Set<String> keys=changes (before, 

extract (this.context.getEnvironment () .getPropertySources () ) ) .k 
this.context.publishEvent (new EnvironmentChangeEvent (keys) ) ; 
this.scope.refreshAll (); 

return keys; 


} 


再 来 看 看 EnvironmentChangeListener 监 听 上 堪 。 
public class EnvironmentChangeListener 


implements 
ApplicationListener<EnvironmentChangeRemoteApplicationEvent> { 
private static Log 


log=LogFactory.getLog (EnvironmentChangeListener.class) ; 

(OAutowired 

private EnvironmentManager enV; 

(DOverride 

public void 
onApplicationEvent (EnvironmentChangeRemoteApplicationEvent event) 
{ 

Map<String,String> values=event.getValues (); 

log.info ("Received remote environment change request.Keys/values to 
update " 

+Values) ; 

for (Map.Entry<String,String> entry : values.entrySet () ) { 

env.setProperty (entry.getKey () ,entry.getValue () ) ; 

} 

} 

} 

它 是 针对 ”EnvironmentChangeRemoteApplicationEvent 事件 的 监听 
类 ， 在 处 理 类 中 ， 可 以 看 到 它 从 
EnvironmentChangeRemoteApplicationEvent 中 获取 了 之 前 提 到 的 事件 中 
定义 的 Map 对 象 ， 然 后 通过 过 历来 更 新 EnvironmentManager 中 的 属性 内 

事件 跟踪 

除了 上 面 介 绍 的 RefreshListener 和 EnvironmentChangeListener 监 听 咒 
外 ， 还 有 一 个 与 它们 都 有 点 不 同 的 TraceListener 监 听 堪 。 

public class TraceListener { 

private static Log log=LogFactory.getLog (TraceListener.class) ; 

private TraceRepository repository; 

public TraceListener (TraceRepository repository ) { 

this.repository=repository; 

} 

(EventListener 


public void onAck (AckRemoteApplicationEvent event ) { 

this.repository.add (getReceivedTrace (event) ) ; 

} 

(EventListener 

public void onSend (SentApplicationEvent event) { 

this.repository.add (getSentTrace (event) ) ; 

} 

protected “Map<String,Object> getSentTrace (SentApplicationEvent 
event) { 

} 

protected Map<String,Object> 
getReceivedTrace (AckRemoteApplicationEvent event) { 

} 

} 

从 之 前 整理 的 类 图 和 源码 中 ， 我 们 都 可 以 看 到 该 监听 器 并 没有 实现 
ApplicationListener 接 口 ， 但 可 以 看 到 这 里 使 用 了 @EventListener 注 解 。 
该 注解 是 从 Spring 4.2 开 始 提 供 的 新 功能 ， 通 过 它 可 以 自动 地 将 函数 注册 
为 一 个 ApplicationListener 的 实现 。 所 以 在 该 类 中 ， 实 际 上 等 价 于 实现 了 
两 个 监听 器 ， 一 个 监听 AckRemoteApplicationEvent 事 件 ， 一 个 监听 
SentApplicationEvent 事 件 。 

在 这 两 个 监听 处 理 函 数 中 调用 了 类 似 的 方法 : 
this.repository.add (getReceivedTrace (event) ) ;， 其 中 TraceRepository 
是 对 Trace 跟踪 信息 的 操作 接口 ， 而 它 的 默认 实现 是 spring-boot-actuator 
模块 的 mMemoryTraceRepository， 有 具体 如 下 : 

public class INMemoryTraceRepository implements TraceRepository { 

Private int capacity=100; 

private boolean reverse=true; 

private final List<Trace> traces=new LinkedList<Trace> (); 

public void setReverse (boolean reverse) { 

synchronized (this.traces) { 

this.reverse=reverse; 

} 

} 

public void setCapacity (int capacity) { 

synchronized (this.traces) { 


this.capacity=capacity; 

} 

} 

(DOverride 

public List<Trace> findAll () { 

synchronized (this.traces) { 

return Collections.unmodifiableList (new 
ArrayList<Trace> (this.traces) ) ; 

} 

} 

(DOverride 

public void add (Map<String,Object> map) { 

Trace trace=new Trace (new Date () ,map) ; 

synchronized (this.traces) { 

while (this.traces.size () >=this.capacity) { 

this.traces.remove (this.reverse ? this.capacity-1 : 0) ; 

} 

if (this.reverse) { 

this.traces.add (0,trace) ; 

} 

else { 

this.traces.add (trace) ; 

} 

} 

} 


} 

可 以 看 到 ， 默 认 的 Trace 跟踪 信息 存储 并 没有 用 到 特别 的 数据 库 或 
消息 系统 ， 而 是 采用 了 内 存 存储 的 方式 。 如 上 代码 所 示 ， 通 过 
LinkedList<Trace> 集 合 和 capacity 属性 的 定义 ， 在 
add (Map<String,Object> map〉 冰 数 中 进行 循环 存储 ， 所 以 默认 的 Trace 
跟踪 实现 只 能 存储 和 查询 最 近 的 100 条 跟踪 信息 。 

那么 跟踪 事件 都 记录 了 哪些 内 容 呢 ? 我 们 继续 看 TraceListener 中 
getSentTrace 和 getReceivedTrace 的 具体 实现 : 

public class TraceListener { 


protected “Map<String,Object> getSentTrace (SentApplicationEvent 
event) { 


Map<String,Object> map=new LinkedHash Map<String,Object> (); 

map.put ("signal","spring.cloud.bus.sent") ; 

map.put ("type",event.getType () .getSimpleName () ) ; 

map.put ("id",event.getld () ) ; 

map.put ("origin",event.getOriginService () ) ; 

map.put ("destination",event.getDestinationService () ) ; 

if (log.isDebugEnabled () ) { 

log.debug (map); 

} 

return map; 

} 

protected Map<String,Object> 
getReceivedTrace (AckRemoteApplicationEvent event) { 

Map<String,Object> map=new LinkedHash Map<String,Object> (); 

map.put ("signal","spring.cloud.bus.ack") ; 

map.put ("event",event.getEvent () .getSimpleName () ) ; 

map.put ("id",event.getAckld () ) ; 

map.put ("origin",event.getOriginService () ) ; 

map.put ("destination",event.getAckDestinationService () ) ; 

if (log.isDebugEnabled () ) { 

log.debug (map ) ; 

| 

return map; 

} 

} 

可 以 看 到 ， 这 两 个 函数 会 收集 天 于 发 送 和 接收 到 的 Ack 事 件 信 息 ， 并 
且 两 个 函数 获得 的 内 容 就 是 事件 定义 相关 的 一 些 属性 ， 看 到 这 里 大 家 古 
否 感 觉 似曾相识 ? 是 的 ， 这 些 信息 与 之 前 我 们 通过 Kafka 的 控制 侣 工具 
获取 的 消息 内 容 非常 类 似 。 既 然 Spring Cloud Bus 已 经 提供 了 Trace 跟踪 
音 恩 的 监听 和 记录 ， 我 们 不 妨 答 试 使 用 一 下 。 要 开局 该 功能 非常 简单 ， 
只 需 在 配置 文件 中 将 下 面 的 属性 设置 为 true 即 可 : 

Spring.cloud.bus.trace.enabled=true 

通过 请 求 配 置 主 机 的 /trace 接 口 ， 比 如 http:Wlocalhost:7002/trace， 可 
以 获得 如 下 信息 ， 

[ 

{ 

"timestamp": 1475129670494， 











"info": { 

"signal": "spring.cloud.bus.ack", 

"event": "RefreshRemoteApplicationEvent", 
"id": "84ecdf83-a904-41bc-a34d-62680ccf35d7", 
"origin": "config-server:7001", 

"destination™: "*:**" 

} 

二 

{ 

"timestamp": 1475129670475, 

"info": { 

"signal": "spring.cloud.bus.sent", 

"type": "RefreshRemoteApplicationEvent", 

"id": "84ecdf83-a904-41bc-a34d-62680ccf35d7", 
"origin": "config-server:7001", 

"destination™: "*:**" 

} 

| 

"timestamp": 1475129670473, 

"info": { 

"signal": "spring.cloud.bus.ack", 

"event": "RefreshRemoteApplicationEvent", 
"id": "84ecdf83-a904-41bc-a34d-62680ccf35d7", 
"origin": "didispace:7002", 

"destination™: "*:**" 

} 

} 


] 

与 我 们 分 析 的 内 容 一 样 ， 该 请 求 返 回 了 最 近 的 Send 和 Ack 消 息 内 容 。 

如 果 和 希望 针对 AckRemoteApplicationEvent 或 是 SentApplicationEvent 做 
一 些 特 殊 处 理 ， 我 们 也 可 以 通过 @EventListener 注 解 在 应 用 程序 中 编写 
自己 的 处 理 逻 辑 ， 或 者 重 写 TraceRepository 来 改造 跟踪 的 存储 等 。 

原则 上 每 一 个 消息 总 线 上 的 应 用 都 可 以 用 来 跟踪 Ack 消 息 ， 但 是 大 多 
数 情况 下 我 们 把 这 个 任务 交 给 更 核心 的 服务 《比如 特定 的 监控 服务 ) ， 
这 样 在 该 服务 中 我 们 就 能 在 Ack 消息 中 实现 更 复杂 的 逻辑 进行 预警 和 善 
站 

事件 发 布 


通过 上 面 的 分 析 ， 我 们 已 经 了 解 了 Spring Cloud Bus 中 事件 以 及 监听 
恬 的 定义 ， 下 面 来 看 看 这 些 事件 是 如 何 发 布 给 监听 费 进 行 处 理 的 。 

在 org.springframework.cloud.bus 包 下 ， 我 们 可 以 找到 关于 Spring 
Cloud Bus 局 动 时 加 载 的 一 些 基础 类 和 接口 ， 包 括 上 自动 化 配置 类 
BusAutoConfiguration、 属 性 定义 类 BusProperties 等 。 我 们 可 以 从 Spring 
Cloud Bus 的 自动 化 配置 类 中 看 看 它 在 启动 的 时 候 都 加 载 了 什么 内 容 : 

(OConfiguration 

(ConditionalOnBusEnabled 

@EnableBinding (SpringCloudBusClient.class ) 

@EnableConfigurationProperties (BusProperties.class) 











public class BusAutoConfiguration implements 
ApplicationEventPublisherAware { 

public static final String 
BUS_ PATH MATCHER NAME="busPathMatcher"; 

(OAutowired 


@Output (SpringCloudBusClient.OUTPUT) 

private MessageChannel cloudBusOutboundChannel; 
(OAutowired 

private Service Matcher ServiceMatcher; 

(OAutowired 

private ChannelBindingServiceProperties bindings; 
(OAutowired 

private BusProperties bus; 

private ApplicationEventPublisher applicationEventPublisher; 





} 

我 们 先 来 看 看 在 该 自动 化 配置 类 中 ， 都 定义 了 哪些 成 员 。 

eMessageChannel cloudBusOutboundChannel: 该 接口 定义 了 发 送 消 
恩 的 抽象 方法 。 

eServiceMatcher ”serviceMatcher: 该 对 象 中 提供 了 下 面 两 个 重要 函 
数 ， 用 来 判断 事件 的 来 源 服务 是 否 为 目 己 ， 以 及 判断 目标 是 售 为 目 己 ， 
以 此 作为 依据 是 否 要 响应 消息 进行 事件 的 处 理 。 

public boolean isFromSelf (RemoteApplicationEvent event) { 

String originService=event.getOriginService 〈) ; 

String serviceld=getServiceld (); 

return this.matcher.match (originService,serviceld) ; 


} 





public boolean isForSelf (RemoteApplicationEvent event) { 

String destinationService=event.getDestinationService () ; 

return (destinationService==null | 
destinationService.trim () .isEmpty〈) |lthis.matcher.match (destinationSe 

} 

eChannelBindingServiceProperties ”bindings: 定义 了 消息 服务 的 绑 定 
属性 。 

eBusProperties bus: 该 对 象 定 义 了 Spring Cloud Bus 的 属性 ， 具 体 如 
下 所 示 。 

@ConfigurationProperties ("spring.cloud.bus") 

public class BusProperties { 

private Env env=new Env (); 

private Refresh refresh=new Refresh 〈) ; 

private Ack ack=new Ack (); 

private Trace trace=new Trace 〈) ; 

Private String destination="springCloudBus"; 

private boolean enabled=true; 


} 
从 中 可 以 看 到 ，Spring Cloud Bus 的 属性 前 缀 使 用 了 
spring.cloud.bus。 destination 和 enabled 属 性 分 别 定义 了 默认 的 队列 
(Queue) 或 主题 〈Topic) 是 否 连接 到 消息 总 线 ， 所 以 我 们 可 以 通过 
spring.cloud.bus.destination 来 修改 消息 总 线 使 用 的 队列 或 主题 名 称 ， 以 
及 使 用 spring.cloud.bus.enabled 属性 来 设置 应 用 是 否 要 连接 到 消息 总 线 


另外 ， 在 该 配置 类 中 为 Env、Refresh、Ack、Trace 4 种 已 经 实现 的 事 
件 分 别 创建 了 配置 对 象 ， 这 些 配 置 类 都 是 BusProperties 的 内 部 类 。 从 下 
面 的 源码 中 ， 我 们 可 以 看 到 对 于 这 4 种 事件 ，Env、Refresh、Ack 均 是 默 
认 开 局 的 ， 只 有 Trace 事件 需要 通过 修改 配置 来 开 司 ， 就 如 之 前 我 们 介 
绍 “ 事 件 跟踪 ”的 时 候 配置 Spring.cloud.bus.trace.enabled=true 属 性 那样 。 

public static class Env { 

private boolean enabled=true; 








} 
public static class Refresh { 
private boolean enabled=true; 


public static class Ack { 

private boolean enabled=true; 

private String destinationService; 

} 

public static class Trace { 

private boolean enabled=false; 

} 

e ApplicationEventPublisher:Spring 事件 模型 中 用 来 发 布 事件 的 接口 ， 
也 就 是 我 们 之 前 介绍 的 事件 以 及 监听 的 桥 染 。 

除了 定义 的 这 些 成 员 变 量 之 外 ， 还 能 看 到 这 里 定义 了 两 个 监听 方法 
acceptLocal 和 acceptRemote。 

其 中 ，acceptLocal 方法 如 下 所 示 ， 它 通过 
@EventListener (classes=RemoteApplicationEvent.class ) 注解 修饰 。 之 
前 已 经 介绍 过 该 注解 ， 可 以 将 该 函数 理解 为 对 RemoteApplicationEvent 
事件 的 监听 器 ， 但 是 在 其 实现 中 并 非 所 有 的 RemoteApplicationEvent 事 件 
都 会 处 理 。 根 据 这 中 的 条 件 ， 可 以 看 到 在 该 监听 处 理 中 ， 只 对 事件 来 源 
是 自己 并 且 事 件 类 型 不 是 AckRemoteApplicationEvent 的 内 容 进 行 后 续 的 
处 理 ， 而 后 续 的 处 理 就 是 通过 消息 管道 将 该 事件 发 送出 去 。 所 以 ， 该 监 
听 响 的 功能 就 是 监听 本 地 事件 来 进行 消息 的 发 送 。 

@EventListener (classes=RemoteApplicationEvent.class ) 

public void acceptLocal (RemoteApplicationEvent event ) { 

if (this.serviceMatcher.isFromSelf (event) 

&& ! (eventinstanceof AckRemoteApplicationEvent) ) { 

this.cloudBusOutboundChannel.send (MessageBuilder.withPayload (ev' 

build () ) ; 

} 


} 

再 来 看 看 acceptRemote 方 法 。 访 方法 中 使 用 了 @StreamListener 注 解 修 
饰 ， 该 注解 的 作用 是 将 该 函数 注册 为 消息 代理 上 数据 流 的 事件 监听 器 ， 
注解 中 的 属性 值 SpringCloudBusClient.INPUT 指定 了 监听 的 通道 名 。 同 
时 ， 回 头 看 该 函数 所 在 类 的 定义 ， 使 用 了 @EnableBinding 注 解 ， 该 注解 
用 来 实现 与 消息 代理 的 连接 ， 注 解 中 的 属性 值 
SpringCloudBusClient.class 声明 了 输入 和 输出 通道 的 定义 《这 部 分 内 容 
源 自 Spring Cloud Stream， 在 下 一 章 中 ， 我 们 会 对 这 些 内 容 做 详细 介 


























绍 ， 这 里 我 们 只 需 理解 它 用 来 绑 定 消息 代理 的 输入 与 输出 ， 以 实现 向 消 
恩 总 线 上 发 送 和 接收 消 恩 即 可 》。 
@StreamListener (SpringCloudBusClient.INPUT) 
public void acceptRemote (RemoteApplicationEvent event) { 
if (event instanceof AckRemoteApplicationEvent) { 
if (this.bus.getTrace () .isEnabled () && ! 
this.serviceMatcher.isFromSelf (event) 
&& this.applicationEventPublisher !=null) { 
this.applicationEventPublisher.publishEvent (event) ; 
M/If it's an ACK we are finished processing at this point 
return; 
} 
if (this.service Matcher.isForSelf (event) 
&& this.applicationEventPublisher !=null) { 
if (! this.serviceMatcher.isFromSelf (event) ) { 
this.applicationEventPublisher.publishEvent (event) ; 
} 
if (this.bus.getAck () .isEnabled () ) { 
AckRemoteApplicationEvent ack=new 
AckRemoteApplicationEvent (this, 
this.serviceMatcher.getServiceId 〈) ， 
this.bus.getAck () .getDestinationService 〈) ， 
event.getDestinationService () ,event.getld () ,event.getClass () ) ; 
this.cloudBusOutboundChannel 
.Send (MessageBuilder.withPayload (ack) .build () ) ; 
this.applicationEventPublisher.publishEvent (ack); 
} 
} 
if (this.bus.getTrace () .isEnabled () && 
this.applicationEventPublisher !=null) { 
//We are set to register sent events so publish it for local consumption, 
//irrespective of the origin 
this.applicationEventPublisher.publishEvent (new 
SentApplicationEvent (this, 
event.getOriginService () ,event.getDestinationService 〈) ， 
event.getId () ,event.getClass () ) ) ; 
} 


通过 上 面 的 分 析 ， 我 们 已 经 可 以 知道 Spring Cloud Bus 通 过 
acceptRemote 方 法 来 监听 消息 代理 的 输入 通道 ， 并 根据 事件 类 型 和 配置 
内 容 来 确定 是 否 要 发 布 事件 给 我 们 之 前 分 析 的 几 个 事件 监听 器 来 对 事件 
做 具体 的 处 理 ， 而 acceptLocal 方 法 用 来 监听 本 地 的 事件 ， 针 对 事件 来 源 
是 自己 ， 并 且 事 件 类 型 不 是 AckRemoteApplicationEvent 的 内 容 通过 消息 
代理 的 输出 通道 发 送 到 总 线 上 去 。 

控制 端点 

在 介绍 了 Spring Cloud Bus 中 实现 的 事件 模型 之 后 ， 我 们 已 经 知道 每 
个 节点 是 如 何 啊 应 消 忠 总 线 上 的 事件 了 。 那 么 这 些 发 送 到 消 明 总 线 上 用 
来 触发 各 个 节点 的 事件 处 理 的 动作 是 如 何 实现 的 呢 ? 回想 一 下 之 前 在 实 
现 配 置 属性 刷新 时 ， 我 们 在 修改 了 Git 仓库 上 的 配置 信息 之 后 ， 往 总 线 
上 的 某 个 节点 发 送 了 一 个 请 求 /bus/refresh 来 触发 总 线 上 的 所 有 节点 进行 
配置 刷新 ; 我 们 在 连接 到 消 轧 总 线 的 应 用 局 动 时 ， 也 能 在 控制 台中 看 到 
类 似 下 面 的 输出 : 

2016-09-30 11:05:13.037 INFO 18720---[ mainl] 

0.s.b.a.e.mvc.EndpointHandlerMapping : Mapped 2 
{[/bus/refreshl,methods=[POST]}" 

onto public void 

org.springframework.cloud.bus.endpoint.RefreshBusEndpoint.refresh (ja 








2016-09-30 11:05:13.045 INFO 18720---[ main] 

0.s.b.a.e.mvc.EndpointHandlerMapping : Mapped 和 
{[/bus/env|],methods=[POST]}" onto 

public void 


org.springframework.cloud.bus.endpoint.EnvironmentBusEndpoint.env ( 

a.lang.String,java.lang.String>,java.lang.String ) 

从 上 面 的 日 志 信 息 中 可 以 看 到 ， 在 
org.Springframework.cloud.bus.endpoint 包 下 的 RefreshBusEndpoint 和 
EnvironmentBusEndpoint 分 别 创建 了 两 个 控制 端点 : /bus/refresh 
和 /bus/env。 通 过 整理 。 org.springframework.cloud.bus.endpoint 包 下 的 内 
容 ， 我 们 可 以 得 到 如 下 类 图 : 


从 图 中 可 以 发 现 ，Spring ”Cloud ”Bus 中 的 Endpoint 也 是 通过 spring- 
boot-actuator 模 块 来 实现 的 。 下 面 ， 简 单 介 绍 一 下 spring-boot-actuator 模 
块 中 的 几 个 重要 元 素 。 

eEndpoint: 该 接口 中 定义 了 监控 端点 需要 骏 露 的 一 些 有 用 信息 ， 比 
如 ，id、 是 否 开启 标识 、 是 否 开启 敏感 信息 标识 等 。 














eAbstractEndPoint: 该 抽象 类 是 对 Endpoint 的 基础 实现 ， 在 该 抽象 类 
中 引入 了 Environment 接 口 对 象 ， 从 而 对 接口 暴露 信息 的 控制 可 以 通过 
配置 文件 的 方式 来 控制 。 

eMvcEndpoint 接 口 : 该 接口 定义 了 Endpoint 接 口 在 MVC 层 的 策略 。 
在 这 里 可 以 通过 使 用 Spring MVC 的 @RequestMapping 注 解 来 定义 端点 暴 
露 的 接口 地 址 。 

下 面 我 们 来 看 看 Spring Cloud Bus 是 如 何 扩展 Endpoint 的 。 

eBusEndpoint: 该 类 继承 自 AbstractEndPoint。 从 类 上 的 注解 
@ConfigurationProperties 配置 可 以 知道 ，Spring Cloud Bus 实现 的 端点 
配置 属性 需要 以 endpoints.bus 开 头 ， 通 过 该 类 的 构造 函数 〈 配 合 
AbstractEndpoint 中 的 构造 函数 ) ， 我 们 可 以 知道 默认 id 为 bus， 并 且 端 
点 默认 敏感 标识 为 true: 

@ConfigurationProperties (prefix="endpoints.bus",ignoreUnknownField 

public class BusEndpoint extends AbstractEndpoint<Collection<String>> 











public BusEndpoint () { 

super ("bus"); 

} 

(DOverride 

public Collection<String> invoke () { 

return Collections.emptyList () ; 

} 

} 

public abstract class AbstractEndpoint< 工 > implements 
Endpoint<T>,EnvironmentAware { 


public AbstractEndpoint (Stringid) { 

this (id,true) ; 

} 

public AbstractEndpoint (String id,boolean sensitive) { 

this.id=id; 

this.sensitiveDefault=sensitive; 

} 

} » » 

eAbstractBusEndpoint 类 是 实现 Spring Cloud Bus 中 端点 的 重要 基 类 ， 
它 实 现 了 MvcEndpoint 接 口 来 暴露 MVC 层 的 接口 ， 同 时 关联 了 





BusEndpoint 对 象 。 通 过 下 面 的 源码 ， 我 们 可 以 看 到 ，getPath、 
isSensitive 和 getEndpointType 都 是 委托 给 BusEndpoint 来 获取 的 ， 从 而 实 
现 通 过 Environment 配 置 接口 。 

public class AbstractBusEndpoint implements MvcEndpoint { 

private ApplicationEventPublisher context; 

private BusEndpoint delegate; 

private String appId; 

public AbstractBusEndpoint (ApplicationEventPublisher context,String 
appld, 

BusEndpoint busEndpoint) { 

this.context=context; 

this.appld=appld; 

this.delegate=busEndpoint; 

} 

protected String getInstanceld () { 

return this.appId; 

} 

protected void publish (ApplicationEvent event) { 

context.publishEvent (event) ; 

} 

(OOverride 

public String getPath () { 

return "/"+this.delegate.getId〈) ; 

} 

(DOverride 

public boolean isSensitive () { 

return this.delegate.isSensitive () ; 

} 

(OOverride 

@SuppressWarnings ("rawtypes") 

public Class<? extends Endpoint> getEndpointType () { 

return this.delegate.getClass (); 

} 


} 

默认 实现 的 几 个 端点 都 继承 自 AbstractBusEndpoint 类 来 实现 MVC 
层 接口 的 暴露 和 配置 ， 下 面 我 们 来 看 看 具体 的 两 个 实现 端点 。 

e 实 现 配 置 刷 新 的 端点 RefreshBusEndpoint 类 。 通 过 下 面 的 源码 ， 我 





们 可 以 看 到 ， 在 该 类 中 定义 了 refresh 的 POST 请 求 ， 由 于 在 BusEndpoint 
默认 构造 时 id 为 bus， 而 AbstractBusEndpoint 中 getPath 函 数 通 过 
BusEndpoint 中 的 id 拼接 而 成 ， 所 以 对 于 RefreshBusEndpoint 中 refresh 请 
求 的 完整 路 径 为 bus/refresh。 同 时 ， 该 请 求 通 过 @RequestParam 注 解 还 
定义 了 一 个 可 选 的 参数 destination， 正 如 在 之 前 的 示例 中 介绍 的 ， 该 参 
数 用 于 指定 刷新 的 服务 实例 。 在 请 求 处 理 部 分 直接 调用 了 父 类 中 的 
publish 函数 将 RefreshRemoteApplicationEvent 事 件 发 布 出 来 ， 实 现在 总 
线 上 发 布 消息 的 功能 。 

public class RefreshBusEndpoint extends AbstractBusEndpoint { 

public RefreshBusEndpoint (ApplicationEventPublisher context,String 
id, 

BusEndpoint delegate) { 

super (context,id,delegate) ; 

} 

@RequestMapping (value="refresh",method=RequestMethod.POST) 

ResponseBody 

public void refresh ( 

@RequestParam (value="destination",required=false ) String 
destination ) { 

publish (new RefreshRemoteApplicationEvent (this,getInstanceld 〈) ， 

destination ) ) ; 

} 

} 

eEnvironmentBusEndpoint 的 实现 与 RefreshBusEndpoint 类 似 ， 通 过 暴 
露 /bus/env 的 POST 请 求 接口 ， 并 提供 了 Map 类 型 的 params 参 数 设 定 需要 
更 新 的 配置 信息 ， 以 及 同 refresh 接 口 一 样 的 destination 参 数 指定 需要 更 新 
的 服务 实例 ， 来 触发 环境 参数 更 新 的 消息 总 线 控制 。 

public class EnvironmentBusEndpoint extends AbstractBusEndpoint { 

public EnvironmentBusEndpoint (ApplicationEventPublisher 
context, String id, 

BusEndpoint delegate) { 

super (context,id,delegate) ; 

} 

@RequestMapping (value="env",method=RequestMethod.POST) 

ResponseBody 

public void env (@RequestParam Map<String,String> params， 

@RequestParam (value="destination",required=false ) String 





destination ) { 
publish (new 

EnvironmentChangeRemoteApplicationEvent (this,getInstanceld 〈) ， 
destination,params) ) ; 





由 于 目前 版 本 的 Spring ”Cloud Bus 只 实现 了 RabbitMQ 和 Kafka 的 封 
装 ， 虽 然 大 部 分 情况 下 ， 这 两 个 产品 的 特性 已 经 涵盖 我 们 大 部 分 的 业务 
场景 ,但 是 由 于 一 些 特殊 需求 或 是 遗留 系统 等 其 他 因素 ， 有 些 团 队 不 得 
不 使 用 其 他 的 消息 代理 ， 这 个 时 候 我 们 就 需要 扩展 消息 代理 的 支持 。 实 
际 上 ， 通 过 之 前 对 源码 的 分 析 ， 我 们 可 以 看 到 ，Spring Cloud Bus 在 绑 定 
具体 消息 代理 的 输入 与 输出 通道 时 均 使 用 了 抽象 接口 的 方式 ， 所 以 真正 
的 实现 来 自 于 spring-cloud-starter-bus-amqp 和 spring-cloud-starter-bus- 
kafka 的 依赖 。 

我 们 可 以 查看 spring-cloud-starter-bus-amqp 和 spring-cloud-starter bus- 
kafka 的 依赖 ， 可 以 看 到 它们 分 别 依 赖 了 spring-cloud-starter-streamrabbit 
和 spring-cloud-starter-stream-kafka， 真 正 实现 与 这 些 消息 代理 进行 交互 
操作 的 是 Spring Cloud Stream。 所 以 ， 我 们 在 本 章 中 使 用 的 所 有 Spring 
Cloud Bus 的 消息 通信 基础 实际 上 都 是 由 Spring Cloud Stream 所 提供 的 。 
一 定 程度 上， 我 们 可 以 将 Spring Cloud Bus 理解 为 是 一 个 使 用 了 Spring 
Cloud Stream 构 建 的 上 层 应 用 。 由 于 Spring Cloud Stream 为 了 让 开发 者 屏 
蔽 各 个 消息 代理 之 间 的 差异 ， 将 来 能 够 方便 地 切换 不 同 的 消息 代理 而 不 
影响 业务 程序 ， 所 以 在 业务 程序 与 消息 代理 之 间 定 义 了 一 层 抽 象 ， 称 为 
绑 定 器 (Binder) 。 我 们 在 整合 RabbitMQ 和 Kafka 的 时 候 就 是 分 别 引入 
了 它们 各 目的 绑 定 右 实 现 ， 可 以 回想 一 下 之 前 的 实现 内 容 ， 不 论 使 用 
RabbitMQ 还 是 Kafka 实现 ， 在 程序 上 其 实 没 有 任何 变化 ， 变 化 的 只 是 
对 绑 定 器 的 配置 。 所 以 ， 当 我 们 要 在 其 他 消息 代理 上 使 用 Spring Cloud 
Bus 消 四 总 线 时 ， 只 需要 去 实现 一 套 指 定 消息 代理 的 绑 定 器 即 可 。 

















第 10 章 消息 驱动 的 微服 务 :，，Sprin 
Cloud Stream 


Spring Cloud Stream 是 一 个 用 来 为 微服 务 应 用 构建 消息 驱动 能 力 的 杠 
架 。 它 可 以 基于 Spring Boot 来 创建 独立 的 、 可 用 于 生产 的 Spring 应 用 程 
序 。 它 通过 使 用 Spring ”Integration 来 连接 消息 代理 中 间 件 以 实现 消息 事 
件 驱 动 。Spring Cloud Stream 为 一 些 供应 商 的 消息 中 间 件 产品 提供 了 个 
性 化 的 自动 化 配置 实现 ， 并 且 引 入 了 发 布 -订阅 、 消 费 组 以 及 分 区 这 三 
个 核心 概念 。 简 单 地 说 ，Spring Cloud Stream 本 质 上 就 是 整合 了 Spring 
Boot 和 Spring Integration， 实 现 了 一 套 轻 量 级 的 消 恩 驱动 的 微服 务 框 
架 。 通 过 使 用 Spring Cloud Stream， 可 以 有 效 简 化 开发 人 员 对 消息 中 间 
件 的 使 用 复杂 上 度 ， 让 系统 开发 人 员 可 以 有 更 多 的 精力 关注 于 核心 业务 逻 
辑 的 处 理 。 由 于 Spring Cloud Stream 基 于 Spring Boot 实 现 ， 所 以 它 秉承 
了 Spring Boot 的 优点 ， 上 自动 化 配置 的 功能 可 帮助 我 们 快速 上 手 使 用 ， 但 
是 到 目前 为 止 ，Spring Cloud Stream 只 支持 下 面 两 个 著名 的 消息 中 间 件 
的 自动 化 配置 : 

e RabbitMQ 

eKafka 

对 于 这 两 个 消息 中 间 件 的 介绍 ， 我 们 在 上 一 章 消 息 总 线 的 内 容 中 己 
有 过 一 些 基础 的 介绍 ， 更 多 关于 这 两 个 消 息 中 间 件 的 高 级 使 用 和 性 能 配 
置 等 内 容 不 在 本 书 的 关注 范围 之 内 读者 在 实际 应 用 中 可 以 查看 它们 的 
官方 文档 或 是 其 他 专业 书籍 进行 进一步 学 习 和 实践 。 
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下 面 我 们 通过 构建 一 个 简单 的 示例 来 对 Spring Cloud Stream 有 一 个 初 

步 认识 。 该 示例 的 主要 目标 是 构建 一 个 基于 Spring Boot 的 微服 务 应 用 ， 
个 微服 务 应 用 将 通过 使 用 消 恩 中 间 件 RabbitMQ 来 接收 消息 并 将 消息 

打印 到 日 志 中 。 所 以 ， 在 进行 下 面 的 步骤 之 前 请 先 确认 已 经 在 本 地 安装 
了 RabbitMQ， 有 只 体 安 装 步 又 可 根据 在 上 一 章 中 的 介绍 来 操作 。 

e 创 建 一 个 基础 的 Spring Boot 工 程 ， 命 名 a hello。 

e 编 辑 pom.xml 中 的 依赖 关系 ， 引 Po Cloud Stream 对 RabbitMQ 
的 支持 ， 具 体 如 下 : 

<parent> 

<groupId>org.Springframework.boot</groupId> 

<artifactId>spring-boot-starter-parent</artifactId> 

<version>1.3.7.RELEASE</version> 

<relativePath/> <!--lookup parent from repository--> 

</parent> 

<dependencies> 

<dependency> 

<groupId>org.Springframework.boot</groupId> 

<artifactId>spring-boot-starter-web</artifactId> 

</dependency> 

<dependency> 

<groupId>org.Springframework.boot</groupId> 

<artifactId>spring-boot-starter-test</artifactId> 

<scope>test</scope> 

</dependency> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-stream-rabbit</artifactId> 

</dependency> 

</dependencies> 

<dependencyManagement> 

<dependencies> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-dependencies</artifactId> 








<version>Brixton.SR5</version> 
<type>pom</type> 
<scope>import</scope> 
</dependency> 

</dependencies> 
</dependencyManagement> 


e 创 建 用 于 接收 来 自 RabbitMQ 消 息 的 消费 者 SinkReceiver， 上 有 具体 如 


@EnableBinding (Sink.class) 

public class SinkReceiver { 

private static Logger 
logger=LoggerFactory.getLogger (HelloApplication.class) ; 

@StreamListener (Sink.INPUT) 

public void receive (Object payload) { 

logger.info ("Received: "+payload) ; 

} 


} 

e 创 建 应 用 主 类 ， 这 里 同 其 他 Spring Boot 一 样 ， 没 有 什么 特别 之 处 ， 
具体 如 下 : 

SpringBootApplication 

public class HelloApplication { 

public static void main (String[largs) { 

SpringApplication.run (HelloApplication.class,args) ; 





} 

到 这 里 ， 快 速 入 门 示 例 的 编码 任务 已 经 完成 了 。 下 面 我 们 分 别 启动 
RabbitMQ 以 及 该 Spring Boot 应 用 ， 然 后 做 下 面 的 测试 ， 看 看 它们 是 如 
何 运作 的 。 

e 先 来 看 一 下 Spring Boot 应 用 的 启动 日 志 。 


INFO 16272--- 
[mainl]o.s.c.s.b.r.RabbitMessageChannelBinder :declaring queue for 

inbound: input.anonymous.Y8VsFILmSC27eS5StsXp6A,bound to: input 

INFO 16272---[mainl]o.s.a.r.c.CachingConnectionFactory : Created 
new 

connection: 
SimpleConnection(@3c78e551[delegate=amqp://guest@127.0.0.1:5672/] 


INFO 16272---[main]o.s.integration.channel.DirectChannel :Channel 
'input.anonymous.Y8VsFILmSC27eS5StsXp6A .bridge' has 1 
subscriber (s) . 
INFO 16272---[mainlo.s.i.a.i.AmgpInboundChannelA dapter 
started 
inbound.input.anonymous.Y8VsFILmSC27eS5StsXp6A 


从 上 面 的 日 志 内 容 中 ， 可 以 获得 以 下 信息 : 
e 使 用 guest 用 户 创建 了 一 个 指向 127.0.0.1:5672 位 置 的 RabbitMQ 连 
接 ， 在 RabbitMQ 的 控制 台中 我 们 也 可 以 发 现 它 


e 声 明了 一 个 名 为 input.anonymous.Y8VsFILmSC27eS5StsXp6A 的 队 
列 ， 0 Rabe ge ane nde 自己 绑 定 为 它 的 消费 者 。 这 
些 信息 我 们 也 能 在 RabbitMQ 的 控制 台中 发 现 它们 。 


下 面 我 们 可 以 在 RabbitMQ 的 控制 台中 进入 
input.anonymous.Y8VsFILmSC27eS5StsXp6A 队 列 的 管理 页 面 ， 通 过 
Publish message 功 能 来 发 送 一 条 消息 到 该 队列 中 。 


此 时 ， 我 们 可 以 在 当前 启动 的 Spring ” Boot 应 用 程序 的 控制 台中 看 到 
下 面 的 内 容 : 

INFO 16272---[C27eS5StsXp6A-1]com.didispace.HelloApplication 
:Received: 

[B@7cba6l0e 

可 以 用 现 在 应 用 控制 台中 输出 的 内 容 就 是 SinkReceiver 中 的 receive 
方法 定义 的 ， 而 输出 的 具体 内 容 则 来 自 消 妃 队列 中 获取 的 对 象 。 这 里 由 
于 我 们 没有 对 消息 进行 序列 化 ， 所 以 输出 的 只 是 该 对 象 的 引用 ， 在 后 面 
的 章节 中 我 们 会 详细 介绍 接收 消息 后 的 处 理 。 

在 ) 顺利 完成 上 面 : 快速 入 门 的 示例 后 ， 我 们 简单 解释 一 下 上 面 的 步骤 
是 如 何 将 我 们 的 Spring Boot 应 用 连接 上 RabbitMQ 来 消费 消息 以 实现 消息 
驱动 业务 逻辑 的 。 

首先 ， 我 们 对 Spring Boot 应 用 做 的 就 是 引入 spring-cloud-starter- 
streamrabbit 依 赖 ， 该 依赖 包 是 Spring Cloud Stream 对 RabbitMQ 支 持 的 封 
装 ， 其 中 包含 了 对 RabbitMQ 的 目 动 化 配置 等 内 容 。 从 下 面 它 定 义 的 依 
赖 关 系 中 ， 我 们 还 可 以 知道 它 等 价 于 spring-cloud-stream-binder-rabbit 依 
赖 。 


<dependencies> 











<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-stream-binder-rabbit</artifactId> 

</dependency> 

</dependencies> 

接着 ， 我 们 再 来 看 看 这 里 用 到 的 几 个 Spring Cloud Stream 的 核心 注 
解 ， 它 们 都 被 定义 在 SinkReceiver 中 

eOEnableBinding， 该 注解 用 来 指定 一 个 或 多 个 定义 了 @Impnut 或 
@Output ”注解 的 接口 ， 以 此 实现 对 消息 通道 (Channel)〉 的 绑 定 。 在 上 
面 的 例子 中 ， 我 们 通过 @EnableBinding (Sink.class) 绑 定 了 Sink 接 
口 ， 该 接口 是 Spring Cloud Stream 中 默认 实现 的 对 输入 消 忠 通道 绑 定 的 
定义 ， 它 的 源码 如 下 : 

public interface Sink { 

String INPUT="input"; 

@Input (Sink.INPUT) 

SubscribableChannel input () ; 








} 

它 通过 @Input 注 解 绑 定 了 一 个 名 为 input 的 通 en 除了 Sink 之 外 ， 
Spring Cloud Stream 还 默认 实现 了 绑 定 output 通道 的 Source 接口 ， 还 有 
结合 了 Sink 和 Source 的 Processor 接 口 ， 实 际 使 用 时 我 们 也 可 以 自己 通过 
@Input 和 @Output 注 解 来 定义 绑 定 消息 通道 的 接口 。 当 需要 为 
@EnableBinding 指定 多 个 接口 来 绑 定 消 息 通 道 的 时 候 ， 可 以 这 样 定 义 : 
@EnableBinding (value={Sink.class,Source. re 

e(@StreamListener: 如 果 已 经 读 过 上 一 章 Spring Cloud Bus 的 源码 分 
析 ， 相 信 对 该 注解 不 会 感到 卫生 。 它 主要 定义 在 方法 上 ， 作 用 是 将 被 修 
饰 的 方法 注册 为 消息 中 间 件 上 数据 流 的 事件 监听 器 ， 注 解 中 的 属性 值 对 
应 了 监听 的 消息 通道 名 。 在 上 面 的 例子 中 ， 我 们 通过 
@StreamListener (Sink.INPUT) 注解 将 receive 方 法 注册 为 input 消 息 通道 
的 监听 处 理 器 ， 所 以 当 我 们 在 RabbitMQ 的 控制 页 面 中 发 布 消 息 的 时 
候 ，receive 方 法 会 做 出 对 应 的 啊 应 动作 。 











核心 概念 


通过 上 一 节 介 绍 的 快速 入 门 示例 ， 相 信 大 家 对 Spring Cloud Stream 的 
工作 模式 已 经 有 了 一 些 基础 概念 ， 比 如 输入 、 输 出 通道 的 绑 定 ， 通 道 消 
恩 事 件 的 监 昕 等 。 在 本 节 中 ， 我 们 将 详细 介绍 在 Spring Cloud Stream 中 
是 如 何 通过 定义 一 些 基础 概念 来 对 各 种 不 同 的 消息 中 间 件 做 抽象 的 。 

下 图 是 官方 文档 中 Spring Cloud Stream 应 用 模型 的 结构 图 。 从 中 我 们 
可 以 看 到 ，Spring Cloud Stream 构 建 的 应 用 程序 与 消息 中 间 件 之 间 是 通 
过 绑 定 器 Binder 相 关联 的 ， 绑 定 器 对 于 应 用 程序 而 言 起 到 了 隅 离 作 用 ， 
它 使 得 不 同 消息 中 间 件 的 实现 细节 对 应 用 程序 来 说 是 透明 的 。 所 以 对 于 
每 一 个 Spring Cloud Stream 的 应 用 程序 来 说 ， 它 不 需要 知晓 消息 中 间 件 
的 通信 细节 ， 它 只 需 知 道 Binder 对 应 程序 提供 的 抽象 概念 来 使 用 消息 中 
间 件 来 实现 业务 逻辑 即 可 ， 而 这 个 抽象 概念 就 是 在 快速 入 门 中 我 们 提 到 
的 消息 通道 ， Channel。 如 下 图 所 示 ， 在 应 用 程序 和 Binder 之 间 定 义 了 两 
条 输入 通道 和 三 条 输出 通道 来 传递 消息 ， 而 绑 定 器 则 是 作为 这 些 通道 和 
消息 中 间 件 之 间 的 桥梁 进行 通信 。 

















心 -> 二 纪 


ee 


Binder 绑 定 器 是 Spring Cloud Stream 中 一 个 非常 重要 的 概念 。 在 没有 
绑 定 器 这 个 概念 的 情况 下 ，Spring Boot 应 用 要 直接 与 消息 中 间 件 进行 信 
奶 交 互 的 时 候 ， 由 于 各 消息 中 间 件 构建 的 初衷 不 同 ， 所 以 它们 在 实现 细 
节 上 会 有 较 大 的 差异 ， 这 使 得 我 们 实现 的 消息 交互 逻辑 就 会 非常 符 重 ， 
因为 对 具体 的 中 间 件 实现 细节 有 太 重 的 依赖 ， 当 中 间 件 有 较 大 的 变动 升 
级 或 是 更 换 中 间 件 的 时 候 ， 我 们 就 需要 付出 非常 大 的 代价 来 实施 。 

通过 定义 绑 定 器 作为 中 间 层 ， 完 美 地 实现 了 应 用 程序 与 消息 中 间 件 
细节 之 间 的 隔离 。 通 过 回应 用 程序 骏 露 统一 的 Channel 通 道 ， 使 得 应 用 
程序 不 需要 再 考虑 各 种 不 同 的 消息 中 间 件 的 实现 。 当 需要 升级 消息 中 间 
件 ， 或 是 更 换 其 他 消息 中 间 件 产品 时 ， 我 们 要 做 的 束 是 更 换 它 们 对 应 的 
Binder 绑 定 器 而 不 需要 修改 任何 Spring Boot 的 应 用 逻辑 。 这 一 点 在 上 一 
章 实 现 消息 总 线 时 ， 从 RabbitMQ 切 换 到 Kafka 的 过 程 中 ， 己 经 能 够 让 我 
们 体验 到 这 一 好 处 。 

目前 版 本 的 Spring Cloud Stream 为 主流 的 消息 中 间 件 产品 RabbitMQ 
和 Kafka 提 供 了 默认 的 Binder 实 现 ， 在 快速 入 门 的 例子 中 ， 我 们 就 使 用 了 
RabbitMQ 的 Binder。 另 外 ，Spring Cloud Stream 还 实现 了 一 个 专门 用 于 















































测试 的 TestSupportBinder， 开 发 者 可 以 直接 使 用 它 来 对 通道 的 接收 内 容 
进行 可 徘 的 测试 断言 。 如 果 要 使 用 除了 RabbitMQ 和 Kafka 以 外 的 消 奶 
| 件 的话 ， 我 们 也 可 以 通过 使 用 它 所 提供 的 扩展 API 来 实现 其 他 中 间 

JBinder。 

仔细 的 读者 可 能 已 经 发 现 ， 我 们 在 快速 入 门 示例 中 ， 并 没有 使 用 
application.properties 或 是 application.yml 来 做 任何 属性 设置 。 那 是 因为 
它 也 秉承 了 Spring Boot 的 设计 理念 ， 提 供 了 对 RabbitMQ 默 认 的 自动 化 
配置 。 当 然 ， 我 们 也 可 以 通过 Spring Boot 应 用 支持 的 任何 方式 来 修改 这 
些 配 置 ， 比 如 ， 通 过 应 用 程序 参数 、 环 境 变 量 、application.properties 或 
是 application.yml 配 置 文件 等 。 比 如 ， 下 面 束 是 通过 配置 文件 来 对 
RabbitMQ 的 连接 信息 以 及 input 通 道 的 主题 进行 配置 的 示例 : 

spring.cloud.stream.bindings.input.destination=raw-sensor-data 

spring.rabbitmgq.host=localhost 

spring.rabbitmq.port=5672 

spring.rabbitmq.username=springcloud 

spring.rabbitmq.password=123456 


及 布 -订阅 模式 


Spring Cloud Stream 中 的 消息 通信 方式 遵循 了 发 布 -订阅 模式 ， 当 一 
条 消息 被 投递 到 消息 中 间 件 之 后 ， 它 会 通过 共享 的 Topic 主 题 进 行 广 
播 ， 消 息 消 费 者 在 订阅 的 主题 中 收 到 它 并 触发 目 身 的 业务 逻辑 处 理 。 这 
里 所 提 到 的 Topic 主 题 是 Spring Cloud Stream 中 的 一 个 抽象 概念 ， 用 来 代 
表 发 布 共 享 消 息 给 消费 者 的 地 方 。 在 不 同 的 消息 中 间 件 中 ，Topic 可 能 
对 应 不 同 的 概念 ， 比 如 ， 在 RabbitMQ 中 ， 它 对 应 Exchange， 而 在 Kakfa 
中 则 对 应 Kafka 中 的 Topic。 

在 快速 入 门 的 示例 中 ， 我 们 通过 RabbitMQ 的 Channel 发 布 消息 给 我 们 
编写 的 应 用 程序 消费 ， 而 实际 上 Spring Cloud Stream 应 用 启动 的 时 候 ， 
在 RabbitMQ 的 Exchange 中 也 创建 了 一 个 名 为 input 的 Exchange 交 换 器 ， 

由 于 Binder 的 隔离 作用 ， 应 用 程序 并 无 法 感知 它 的 存在 ， 应 用 程序 只 知 
道上 自己 指 癌 Binder 的 输入 或 是 输出 通道 。 为 了 直观 地 感受 在 发 布 -订阅 模 
式 中 ， 消 息 是 如 何 被 分 发 到 多 个 订阅 者 的 ， 我 们 可 以 使 用 快速 入 门 的 例 
子 ， 通 过 命令 行 的 方式 启动 两 个 不 同 端口 的 进程 。 此 时 ， 我 们 在 
RabbitMQ 控制 页 面 的 Channels 选 项 卡 中 看 到 如 下 图 所 示 的 两 个 消息 通 
道 ， 它 们 分 别 绑 定 了 局 动 的 两 个 应 用 程序 。 


而 在 Exchanges 选 项 卡 中 ， 我 们 还 能 找到 名 为 input 的 交换 堪 ， 单 击 进 






































入 可 以 看 到 如 下 图 所 示 的 详情 页 面 。Bindings 栏 中 的 内 容 就 是 两 个 应 用 

程序 绑 定 通道 中 的 消息 队列 ， 我 们 可 以 通过 Exchange 页 面 的 Publish 

妃 ， 此 时 可 以 发 现 两 个 启动 的 应 用 程序 都 输出 了 消 县 
容 。 


下 图 总 结 了 我 们 上 面 所 做 尝试 的 基础 结构 。 启 动 的 两 个 应 用 程序 分 
别 是 “订阅 者 -1 和 “订阅 者 -2”， 它 们 都 建立 了 一 条 输入 通道 绑 定 到 同一 
个 Topic (RabbitMQ 的 Exchange) 上 。 当 该 Topic 中 有 消息 发 布 进来 后 ， 
的 所 有 订阅 者 可 以 收 到 该 消息 并 根据 自身 的 需求 进行 
滑 费 操作 。 


相对 于 点 对 点 队列 实现 的 消息 通信 来 说 ，Spring Cloud Stream 采 用 的 
发 布 -订阅 模式 可 以 有 效 降 低 消 息 生 产 者 与 消费 者 之 间 的 耦合 。 当 需要 
对 同一 类 消息 增加 一 种 处 理 方 式 时 ， 只 需要 增加 一 个 应 用 程序 并 将 输入 
通道 绑 定 到 既 有 的 Topic 中 束 可 以 实现 功能 的 扩展 ， 而 不 需要 改变 原来 
己 经 实现 的 任何 内 容 。 


消费 组 


虽然 Spring Cloud Stream 通 过 发 布 -订阅 模式 将 消息 生产 者 与 消费 者 
做 了 很 好 的 解 炸 ， 基 于 相同 主题 的 消费 者 可 以 轻松 地 进行 扩展 ， 但 是 这 
些 扩 展 都 是 针对 不 同 的 应 用 实例 而 言 的 。 在 现实 的 微服 务 架构 中 ， 我 们 
的 每 一 个 微服 务 应 用 为 了 实现 高 可 用 和 人 负载 均衡 ， 实 际 上 都 会 部 昔 多 个 
实例 。 在 很 多 情况 下 ， 消 息 生 产 者 发 送 消 筷 给 某 个 具体 微服 务 时 ， 只 项 
望 被 消费 一 次 ， 按 照 上 面 我 们 启动 两 个 应 用 的 例子 ， 虽 然 它 们 同属 一 个 
应 用 ， 但 是 这 个 消息 出 现 了 被 重复 消费 两 次 的 情况 。 为 了 解决 这 个 问 
题 ， 在 Spring Cloud Stream 中 提供 了 消费 组 的 概念 。 

如 果 在 同一 个 主题 上 的 应 用 需要 启动 多 个 实例 的 时 候 ， 我 们 可 以 通 
过 spring.cloud.stream.bindings.input.group 属 性 为 应 用 指定 一 个 组 名 ， 这 
样 这 个 应 用 的 多 个 实例 在 接收 到 消息 的 时 候 ， 只 会 有 一 个 成 员 真 正 收 到 
消息 并 进行 处 理 。 如 下 图 所 示 ， 我 们 为 Service-A 和 Service-B 分 别 启动 
了 两 个 实例 ， 并 且 根 据 服务 名 进行 了 分 组 ， 这 样 当 消息 进入 主题 之 后 ， 
Group-A 和 Group-B 都 会 收 到 消息 的 副本 ， 但 是 在 两 个 组 中 都 只 会 有 一 个 
实例 对 其 进行 消费 。 


默认 情况 下 ， 当 没有 为 应 用 指定 消费 组 的 时 候 ，Spring Cloud Stream 
会 为 其 分 配 一 个 独立 的 匿名 消费 组 。 所 以 ， 如 果 同 一 主题 下 的 所 有 应 用 
























































都 没有 被 指定 消费 组 的 时 候 ， 当 有 消息 发 布 之 后 ， 所 有 的 应 用 都 会 对 其 
进行 消费 ， 因 为 它们 各 自 都 属于 一 个 独立 的 组 。 大 部 分 情况 下 ， 我 们 在 
创建 Spring Cloud Stream 应 用 的 时 候 ， 建 议 最 好 为 其 指定 一 个 消费 组 ， 
“J 除非 该 行为 需要 这 样 做 〔( 比 如 刷新 所 有 实例 
配置 导 3 


消 局 分 | x 


通过 引入 消费 组 的 概念 ， 我 们 已 经 能 够 在 多 实例 的 情况 下 ， 保 障 每 
个 消息 只 被 组 内 的 一 个 实例 消费 。 通 过 上 面 对 消 费 组 参数 设置 后 的 实 
验 ， 我 们 可 以 观察 到 ， 消 费 组 无 法 控制 消息 具体 被 哪个 实例 消费 。 也 天 
是 说 ， 对 于 同一 条 消息 ， 它 多 次 到 达 之 后 可 能 是 由 不 同 的 实例 进行 消费 
的 。 但 是 对 于 一 些 业 务 场景 ， 需 要 对 一 些 具 有 相同 特征 的 消息 设置 每 次 
都 被 同一 个 消费 实例 处 理 ， 比 如 ， 一 些 用 于 监控 服务 ， 为 了 统计 某 段 时 
间 内 消息 生产 者 发 送 的 报告 内 容 ， 监 控 服 务 需要 在 自身 聚合 这 些 数据 ， 
那么 消 朋 生产 者 可 以 为 消息 增加 一 个 固有 的 特征 ID 来 进行 分 区 ， 使 得 拥 
有 这 些 ID 的 消息 每 次 都 能 被 发 送 到 一 个 特定 的 实例 上 实现 累计 统计 的 效 
果 ， 否 则 这 些 数 据 就 会 分 散 到 各 个 不 同 的 节点 导致 监控 结果 不 一 致 的 情 
况 。 而 分 区 概念 的 引入 就 是 为 了 解决 这 样 的 问题 ， 当 生产 者 将 消 恩 数据 
发 送 给 多 个 消费 者 实例 时 ， 保 证 拥有 共同 特征 的 消息 数据 始终 是 由 同一 
个 消费 者 实例 接收 和 处 理 。 

Spring Cloud Stream 为 分 区 提供 了 通用 的 抽象 实现 ， 用 来 在 消息 中 间 
件 的 上 层 实现 分 区 处 理 ， 所 以 它 对 于 消息 中 间 件 自身 是 否 实现 了 消息 分 
区 并 不 关心 ， 这 使 得 Spring Cloud Stream 为 不 具备 分 区 功能 的 消息 中 间 
件 也 增加 了 分 区 功能 扩展 。 























MA) 7 


在 介绍 了 Spring Cloud Steam 的 基础 结构 和 核心 概念 之 后 ， 下 面 我 们 
来 详细 地 学 习 一 下 它 所 提供 的 一 些 核心 注解 的 具体 使 用 方法 。 


a 全 已 
在 Spring Cloud Stream 中 ， 我 们 需 ee 为 应 
用 局 动 消息 驱动 的 功能 ， 该 注解 我 们 在 快速 入 门 中 已 经 有 了 基本 的 介 
绍 ， 下 面 来 详细 看 看 它 的 定义 : 
@Target ({ElementType.TYPE,ElementType.ANNOTATION_TYPE}) 
@Retention (RetentionPolicy.RUNTIME) 
Documented 
QInherited 
@Configuration 
@Import ({ 
ChannelBindingServiceConfiguration.class, 
BindingBeansRegistrar.class, 
BinderFactoryConfiguration.class， 
SpelExpressionConverterConfiguration.class}) 
(@EnableIntegration 
public @interface EnableBinding { 
Class<? >[]value () default {}: 








} 

从 该 注解 的 定义 中 我 们 可 以 看 到 ， 它 自身 包含 了 @Configuration 注 
解 ， 所 以 用 它 注解 的 类 也 会 成 为 Spring 的 基本 配置 类 。 另 外 访 注 解 还 通 

过 @Import 加 载 了 Spring Cloud Stream 运 行 需 要 的 ) L 个 基础 配置 类 。 

eChannelBindingServiceConfiguration: 该 配置 会 加 载 消 息 通 道 绑 定 
必要 的 一 些 实例 ， 比 如 ， 用 于 处 理 消 息 通 道 绑 定 的 
ChannelBindingService 实例 、 消 息 类 型 转换 器 
MessageConverterConfigurer、 消 息 通 道 工 厂 BindableChannelFactory 等 重 
有 兴趣 的 读者 可 以 上 自行 查看 这 些 默 认 配置 ， 以 对 其 有 更 深入 的 
理解 。 

eBindingBeansRegistrar: 该 类 是 ImportBeanDefinitionRegistrar 接 口 的 


实现 ， 主 要 是 在 Spring 加 载 Bean 的 时 候 被 调用 ， 用 来 实现 加 载 更 多 的 














Bean。 由 于 BindingBeansRegistrar 被 @EnableBinding 注 解 的 @Import 所 引 
用 ， 所 以 在 其 他 配置 加 载 完 后 ， 它 的 实现 会 被 回调 来 创建 其 他 的 Bean， 
而 这 些 Bean 则 从 @EnableBinding 注 解 的 value 属 性 定义 的 类 中 获取 。 束 如 
我 们 入 门 实例 中 定义 的 @EnableBinding 〈Sink.class) ， 它 在 加 载 用 于 消 
恩 驱 动 的 基础 Bean 之 后 ， 会 继续 加 载 Sink 中 定义 的 具体 消息 通道 绑 定 。 
eBinderFactoryConfiguration:Binder 工 三 的 配置 ， 主 要 用 来 加 载 与 消 
居中 间 件 相关 的 配置 信息 ， 比 如 ， 它 会 从 应 用 工程 的 META- 
INF/spring.binders 中 加 载 针 对 具体 消 奶 中 间 件 相关 的 配置 文件 等 。 
eSpelExpressionConverterConfiguration:SpEL 表 达 式 转换 器 配置 。 
@EnableBinding 注 解 只 有 一 个 唯一 的 属性 : value。 上 面 已 经 介绍 
过 ， 由 于 该 注解 @Import 了 BindingBeansRegistrar 实 现 ， 所 以 在 加 载 了 基 
础 配置 内 容 之 后 ， 它 会 回调 来 读 取 value 中 的 类 ， 以 创建 消息 通道 的 绑 
定 。 另 外 ， 由 于 value 是 一 个 Class 类 型 的 数组 ， 所 以 我 们 可 以 通过 value 
属性 一 次 性 指定 多 个 关于 消息 通道 的 配置 。 


> My » NAY 
消息 通道 














在 Spring Cloud _ Steam 中， 我 们 可 以 在 接口 中 通过 @Input 和 @Outpnut 
注解 来 定义 消息 通道 ， 而 用 于 定义 绑 定 消息 通道 的 接口 则 可 以 被 
@EnableBinding 注 解 的 value 参 数 来 指定 ， 从 而 在 应 用 局 动 的 时 候 实现 对 
定义 消息 通道 的 绑 定 。 

在 快速 入 门 的 示例 中 ， 我 们 活 示 了 使 用 Sink 接 口 绑 定 的 消息 通道 。 
Sink 接 口 是 Spring ”Cloud ”Steam 提供 的 一 个 默认 实现 ， 除 此 之 外 还 有 
Source 和 Processor， 可 从 它们 的 源码 中 学 习 它 们 的 定义 方式 : 

public interface Sink { 

String INPUT="input"; 

@Input (Sink.INPUT) 

SubscribableChannel input 〈) ; 

} 

public interface Source { 

String OUTPUT="output"; 

@Output (Source.OUTPUT) 

MessageChannel output () ; 

} 


public interface Processor extends Source,Sink { 





} 
从 上 面 的 源码 中 ， 我 们 可 以 看 到 ，Sink 和 Source 中 分 别 通 过 @Input 和 


@Output 注 解 定 义 了 输入 通道 和 输出 通道 ， 而 Processor 通 过 继承 Source 
和 Sink 的 方式 同时 定义 了 一 个 输入 通道 和 一 个 输出 通道 。 

另外 ，@Input 和 @Output 注 解 都 还 有 一 个 value 属 性 ， 访 属性 可 以 用 
来 设置 消息 通道 的 名 称 ， 这 里 Sink 和 Source 中 指定 的 消息 通道 名 称 分 别 
为 input 和 output。 如 果 我 们 直接 使 用 这 两 个 注解 而 没有 指定 具体 的 value 
值 ， 将 默认 使 用 方法 名 作为 消息 通道 的 名 称 。 

最 后 ， 需 要 注意 一 点 ， 当 我 们 定义 输出 通道 的 时 候 ， 需 要 返回 
MessageChannel 接口 对 象 ， 该 接口 定义 了 回 消 息 通道 发 送 消 息 的 方法 ; 
而 定义 输入 通道 时 ， 需 要 返回 SubscribableChannel 接 口 对 象 ， 该 接口 继 
承 自 MessageChannel 接 口 ， 它 定义 了 维护 消息 通道 订阅 者 的 方法 。 

注入 绑 定 接口 

在 完成 了 消息 通道 绑 定 的 定义 之 后 ，Spring Cloud Stream 会 为 其 创建 
具体 的 实例 ， 而 开发 者 只 需要 通过 注入 的 方式 来 获取 这 些 实例 并 直接 使 
用 即 可 。 举 个 简单 的 例子 ， 我 们 在 快速 入 门 示例 中 已 经 为 Sink 接 口 绑 定 
的 input 消 轧 通道 实现 了 具体 的 消 恩 消费 者 ， 下 面 可 以 通过 注入 的 方式 实 
现 一 个 消息 生成 者 ， 癌 input 消 息 通 道 及 送 数 据 。 

e 创 建 一 个 将 Input 消息 通道 作为 输出 通道 的 接口 ， 有 具体 如 下 ; 

public interface SinkSender { 

@Output (Sink.INPUT) 

MessageChannel output 〈) ; 




















} 

e 对 快速 入 门 中 定义 的 SinkReceiver 做 一 些 修改 : 在 @EnableBinding 
注解 中 增加 对 SinkSender 接 口 的 指定 ， 使 Spring Cloud Stream 能 创建 出 对 
应 的 实例 。 

@EnableBinding (value={Sink.class,SinkSender.class}) 

public class SinkReceiver { 

private static Logger 
logger=LoggerFactory.getLogger (SinkReceiver.class) ; 

@StreamListener (Sink.INPUT) 

public void receive (Object payload) { 

logger.info ("Received: "+payload) ; 

} 


} 

e 创 建 一 个 单元 测试 类 ， 通 过 @Autowired 注 解 注入 SinkSender 的 实 
例 ， 并 在 测试 用 例 中 调用 它 的 发送 消 居 方 法 。 

@RunWith (SpringJUnit4ClassRunner.class) 

@SpringApplicationConfiguration (classes=HelloApplication.class) 


@WebAppConfiguration 

public class HelloApplicationTests { 

(OAutowired 

private SinkSender sinkSender; 

(@Test 

public void contextLoads () { 

sinkSender.output () .send (MessageBuilder.withPayload ("From 
SinkSender") .build () ) ; 

} 


} 

e 运 行 该 单元 测试 用 例 ， 如 果 可 以 在 控制 台中 找到 如 下 输出 内 容 ， 表 
明 我 们 的 试验 已 经 成 功 了 ， 消 息 被 正确 地 发 送 到 了 input 通 道中 ， 并 被 相 
对 应 的 消息 消费 者 输出 。 


INFO 10656---[ 
mainlcom.didispace.HelloApplication : Received: 
From SinkSender 


注入 消息 通道 

由 于 Spring Cloud Stream 会 根据 绑 定 接口 中 的 @Imnput 和 @Output 注 解 
来 创建 消 轧 通道 实例 ， 所 以 我 们 也 可 以 通过 直接 注入 的 方式 来 使 用 消 居 
通道 对 象 。 比 如 ， 我 们 可 以 通过 下 面 的 示例 ， 注 入 上 面 例子 中 
SinkSender 接 口中 定义 的 名 为 input 的 消息 输入 通道 。 

@RunWith 《SpringJUnit4ClassRunner.class ) 

@SpringApplicationConfiguration (classes=HelloApplication.class) 

@WebAppConfiguration 

public class HelloApplicationTests { 

(OAutowired 

private MessageChannel input; 

(@Test 

public void contextLoads () { 

input.send (MessageBuilder.withPayload ("From 
MessageChannel") .build () ) ; 

} 


} 
上 面 定义 的 内 容 ， 完 成 了 与 之 前 通过 注入 绑 定 接口 SinkSender 方 式 实 
现 的 测试 用 例 相 同 的 操作 。 因 为 在 通过 注入 绑 定 接口 实现 时 ， 











sinkSender.output 〈) 方 了 天 得 的 就 是 SinkSender 接 口中 定义 的 
MessageChannel 实 例 ， 只 是 在 这 里 我 们 直接 通过 注入 的 方式 来 实现 了 而 
己 。 这 种 用 法 虽然 很 直接 ， 但 是 也 容易 犯错 ， 很 多 时 候 我 们 在 一 个 微服 
务 应 用 中 可 能 会 创建 多 个 不 同名 的 MessageChannel 实 例 ， 这 样 通过 
@Autowired 注 入 时 ， 要 注意 参数 命 名 需要 与 通道 同名 才能 被 正确 注入 ， 
或 者 也 可 以 使 用 @Qualifier 注 解 来 特别 指定 具体 实例 的 名 称 ， 该 名 称 需 
要 与 定义 MessageChannel 的 @Output 中 的 value 参 数 -一 致 ， 人 能 被 
正确 注入 。 比 如 下 面 的 例子 ， 在 一 个 接口 中 定义 了 两 个 输出 通道 ， 人 
命名 为 Output-1 和 Output-2， 当 要 使 用 Output-1 的 时 候 ， 可 以 通过 

@Ovalifier ("Output-1") 来 指定 这 个 具体 的 实例 来 注入 使 用 。 

public interface MySource { 

@Output ("Output-1") 

MessageChannel outputl (); 

@Output ("Output-2") 

MessageChannel output2 〈) ; 

} 

@Component 

public class OutputSender { 

@Autowired @Qualifier ("Output-1") 

private MessageChannel output; 











} 
消息 牛 产 与 消费 








由 于 Spring Cloud Stream 是 基于 Spring Integration 构建 起 来 的 ， 所 
以 在 使 用 Spring Cloud Stream 构 建 消 息 驱 动 服 务 的 时 候 ， 完 全 可 以 使 用 
Spring _ Integration 的 原生 注解 来 实现 各 种 业务 需求 。 同 时 ， 为 了 简化 面 
向 消息 的 编程 模型 ，Spring Cloud Stream 还 提供 了 @StreamListener 注 解 
对 输入 通道 的 处 理 做 了 进一步 优化 。 下 面 我 们 分 别 从 这 两 方面 来 学 习 一 
下 对 消息 的 处 理 。 

Spring Integration 原 生 支 持 

通过 之 前 的 内 容 ， 我 们 已 经 能 够 通过 注入 绑 定 接口 和 消息 通道 的 方 
式 实现 向 名 为 input 的 消息 通道 发 送信 息 。 接 下 来 ， 我 们 通过 Spring 
Integration 原 生 的 @ServiceActivator 和 Q@InboundChannelAdapter 注 解 来 尝 
试 实现 相同 的 功能 ， 有 基体 实现 如 下 : 

@EnableBinding (value={Sink.class}) 





public class SinkReceiver { 

private static Logger 
logger=LoggerFactory.getLogger (SinkReceiver.class) ; 

@ServiceActivator (inputChannel=Sink.INPUT) 

public void receive (Object payload) { 

logger.info ("Received: "+payload) ; 

} 

} 

@EnableBinding (value={SinkSender.SinkOutput.class}) 

public class SinkSender { 


private static Logger 
logger=LoggerFactory.getLogger (SinkSender.class) ; 
Bean 


@InboundChannelAdapter (value=SinkOutput.OUTPUT,poller=@Poller 
public MessageSource<Date> timerMessageSource () { 

return () -> new GenericMessage<> (new Date () ) ; 

} 

public interface SinkOutput { 

String OUTPUT="input"; 

@Output (SinkOutput.OUTPUT) 

MessageChannel output () ; 

} 


} 
上 面 展 示 的 两 段 代 码 分 别 属于 两 个 不 同 的 应 用 。 
eSinkReceiver 类 属于 消息 消费 者 实现 ， 与 之 前 实现 的 类 似 ， 只 是 做 








了 一 些 修改 : 使 用 原生 的 @ServiceActivator 注解 替换 了 
@StreamListener， 实 现 对 Sink.INPUT 通 道 的 监听 处 理 ， 而 该 通道 绑 定 了 
名 为 input 的 主题 。 





eSinkSender 类 属于 消息 生产 者 实现 ， 它 在 内 部 定义 了 SinkOutput 接 
口 来 将 输出 通道 绑 定 到 名 为 input 的 主题 中 。 由 于 SinkSender 和 
SinkReceiver 共 用 一 个 主题 ， 所 以 它们 构成 了 一 组 生产 者 与 消费 者 。 男 
外 ， 在 SinkSender 中 还 创建 了 用 于 生产 消息 的 timerMessageSource 方 
法 ， 该 方法 会 将 当前 时 间作 为 消息 返回 。 而 @InboundChannelAdapter 注 
解 定义 了 该 方法 是 对 SinkOutput.OUTPUT 通 道 的 输出 绑 定 ， 同 时 使 用 
poller 参 数 将 该 方法 设置 为 轮 询 执行 ， 这 里 我 们 定义 为 2000 室 秒 ， 所 以 
它 会 以 2 秒 的 频率 向 SinkOutput.OUTPUT 通 道 输出 当前 时 间 。 执 行 上 面 
定义 的 程序 ， 可 以 得 到 类 似 下 面 的 输出 : 


INFO 248---[ask-schedujler-2]jcom.didispace.HelljoApplication 
Received: 

Sun Nov 13 11:22:39 CST 2016 

INFO 248---[ask-scheduler-3]lcom.didispace.HelloApplication 
Received: 

Sun Nov 13 11:22:41 CST 2016 

INFO 248---[ask-schedujler-2]jcom.didispace.HelljoApplication 
Received: 

Sun Nov 13 11:22:43 CST 2016 

INFO 248---[ask-scheduler-1lcom.didispace.HelloApplication 
Received: 

Sun Nov 13 11:22:45 CST 2016 

INFO 248---[ask-scheduler-5lcom.didispace.HelloApplication 
Received: 

Sun Nov 13 11:22:47 CST 2016 


另外 ， 还 可 以 通过 @Transformer 注 解 对 指定 通道 的 消息 进行 转换 。 


比如 ， 我 们 可 以 在 上 面 的 SinkSender 类 中 增加 下 面 的 内 容 : 


@Transformer (inputChannel=Sink.INPUT,outputChannel=Sink.INPUT 


public Object transform (Date message) { 


return new SimpleDateFormat ("yyyy-MM-dd 


HH:mm:ss") .format (message) ; 





} 
再 次 执行 程序 ， 可 以 得 到 下 面 的 输出 内 容 ， 消 轧 内 容 被 成 功 转 换 为 


yyyy-MM-dd HH:mm:ss 格 式 了 。 


INFO 22092---[ask-scheduler- 
2]com.didispace.HelloApplication :Received: 

2016-11-13 12:12:21 

INFO 22092---[ask-scheduler- 
3]com.didispace.HelloApplication :Received: 

2016-11-13 12:12:23 

INFO 22092---[ask-scheduler- 
2]com.didispace.HelloApplication :Received: 

2016-11-13 12:12:25 

INFO 22092---[ask-scheduler- 
1jcom.didispace.HelljoApplication :Received: 


2016-11-13 12:12:27 


INFO 22092---[ask-scheduler- 


5jcom.didispace.HelljoApplication :Received: 

2016-11-13 12:12:29 

更 多 关于 Spring Integration 的 使 用 细节 请 查阅 官方 文档 。 

@StreamListener 详 解 

通过 入 门 示 例 ， 对 于 @StreamListener 注 解 ， 大 家 应 该 都 已 经 有 了 一 
些 基本 的 认识 ， 通 过 该 注解 修饰 的 方法 ，Spring Cloud Steam 会 将 其 注册 
为 输入 消 明 通道 的 监听 器 。 当 输入 消 明 通道 中 有 消 朋 到 达 的 时 候 ， 会 江 
即 触发 该 注解 修饰 方法 的 处 理 逻 辑 对 消 晨 进行 消费 。 

消息 转换 

@SteamListener 和 (@ServiceActivator 注 解 都 实现 了 对 输入 消息 通道 的 
监听 ， 但 是 @SteamListener 相 比 @ServiceActivator 更 为 强大 ， 因 为 它 还 
内 置 了 一 系列 的 消息 转换 功能 ， 这 使 得 基于 @SteamListener 注 解 实 现 的 
消息 处 理 模型 更 为 简单 。 

大 部 分 情况 下 ， 我 们 通过 消息 来 对 接 服务 或 系统 时 ， 消 息 生 产 者 都 
会 以 结构 化 的 字符 串 形 式 来 发 送 ， 比 如 JSON 或 XML 。 当 消息 到 达 的 时 
候 ， 输 入 通道 的 监听 圳 需要 对 该 字符 串 做 一 定 的 转化 ， 将 JSON 或 XML 
转换 成 具体 的 对 象 ， 然 后 再 做 后 续 的 处 理 。 

假设 ， 我 们 需要 传输 一 个 User 对 象 ， 该 对 象 有 name 和 age 两 个 字段 ， 
这 时 ， 如 果 使 用 @ServiceActivator 注 解 的 话 ， 可 以 通过 下 面 的 代码 实 
现 : 

@EnableBinding (value={Sink.class}) 

public class SinkReceiver { 

private static Logger 
logger=LoggerFactory.getLogger (SinkReceiver.class) ; 

@ServiceActivator (inputChannel=Sink.INPUT) 

public void receive (User user) { 

logger.info ("Received: "+user) ; 














@Transformer (inputChannel=Sink.INPUT,outputChannel=Sink.INPUT 
public User transform (String message) throws Exception { 
ObjectMapper objectMapper=new ObjectMapper (); 

User User=objectMapper.readValue (message,User.class) ; 

return user; 


} 


} 
@EnableBinding (value={SinkSender.SinkOutput.class}) 
public class SinkSender { 


Private static Logger 
logger=LoggerFactory.getLogger (SinkSender.class) ; 

Bean 

@InboundChannelAdapter (value=Sink.INPUT,poller=@Poller (fixedD 

public MessageSource<String> timerMessageSource () { 


return () -> new GenericMessage<> (" 
{\"name\":\"didi\",\"age\":30}") ; 
} 


public interface SinkOutput { 

String OUTPUT="input"; 

@Output (SinkOutput.OUTPUT) 

MessageChannel output (); 

} 

} 

由 于 @ServiceActivator 本 和 号 不 具备 对 消 恩 的 转换 能 力 ， 所 以 当代 表 
User 对 象 的 JSON 字符 串 到 达 后 ， 它 自身 无 法 将 其 转换 成 User 对 象 。 所 
以 ， 这 里 需要 通过 @Transformer “注解 帮助 将 字符 串 类 型 的 消息 转换 成 
User 对 象 ， 并 将 转换 结果 传递 给 @ServiceActivator 的 处 理 方法 做 后 续 的 
消费 。 

如 果 我 们 使 用 @SteamListener 注 解 的 话 ， 就 可 以 把 上 面 的 实现 简化 为 
下 面 的 代码 : 

@EnableBinding (value={Sink.class} ) 

public class SinkReceiver { 

private static Logger 
logger=LoggerFactory.getLogger (SinkReceiver.class) ; 

@StreamListener (Sink.INPUT) 

public void receive (User user) { 

logger.info ("Received: "+user) ; 


} 


} 

从 上 面 的 实现 中 可 以 看 到 ， 我 们 去 挥 了 @Transformer 注解 的 方法 ， 
同时 用 @StreamListener 蔡 代 了 @ServiceActivator 注 解 ， 而 SinkSender 类 
不 需要 做 任何 修改 ， 只 需 在 配置 文件 中 增加 
spring.cloud.stream.bindings.input.contenttype=application/json 属 性 设置 ， 
这 样 我 们 可 以 得 到 与 之 前 一 样 的 结果 。 

@StreamListener 注 解 能 够 通过 配置 属性 实现 JSON 字 符 串 到 对 象 的 转 
换 ， 这 是 因为 在 Spring Cloud Steam 中 实现 了 一 套 可 扩展 的 消息 转换 机 























制 。 在 消息 消费 逻辑 执行 之 前 ， 消 息 转 换 机 制 会 根据 消息 头 信息 中 声明 
的 消息 类 型 〈 即 上 面 对 input 通道 配置 的 content-type 参 数 ) ， 找 到 对 应 
的 消 朋 转换 器 并 实现 对 消息 的 目 动 转换 。 

消息 反馈 

很 多 时 候 在 处 理 完 输入 消 轧 之 后 ， 需 要 反馈 一 个 消息 给 对 方 ， 这 时 
候 可 以 通过 @SendTo 注 解 来 指定 返回 内 容 的 输出 通道 。 

比如 ， 假 设 我 们 有 这 样 的 两 个 应 用 ，App1 和 App2。 

eApp1 中 实现 了 对 input 输 入 通道 的 监听 ， 并 且 在 接收 到 消息 之 后 ， 
对 消 息 做 了 一 些 简 单 加 工 ， 然 后 通过 @SendTo ”把 处 理 方法 返回 的 内 容 
以 消息 的 方式 发 送 到 output 通 道中 ， 有 具体 如 下 : 

@EnableBinding (value={Processor.class}) 

public class Appl { 

private static Logger logger=LoggerFactory.getLogger (Appl.class) ; 

@StreamListener (Processor.INPUT) 

@SendTo (Processor.OUTPUT) 

public Object receiveFromInput (Object payload) { 

logger.info ("Received: "+payload) ; 

return "From Input Channel Return-"+payload; 


} 


} 

eApp2 是 App1 应 用 中 input 通 道 的 生产 者 以 及 output 通 道 的 消费 者 。 为 
了 继续 使 用 Processor 绑 定 接口 的 定义 ， 我 们 可 以 在 配置 文件 中 将 该 应 
用 的 input 和 output 绑 定 反 同 地 做 一 些 配 置 。 因 为 对 于 App2 来 说 ， 它 的 
input 绑 定 通 道 实际 上 是 对 output 主 题 的 消费 者 ， 而 output 绑 定 通 道 实际 上 
是 对 input 主 题 的 生产 者 ， 所 以 我 们 可 以 做 如 下 具体 配置 。 指 定 通 道 的 具 
体 主题 来 实现 与 App1 应 用 的 消息 交互 : 

Spring.cloud.stream.bindings.input.destination=output 

Spring.cloud.stream.bindings.output.destination=input 

eApp2 中 程序 的 逻辑 实现 如 下 所 示 。 通 过 timerMessageSource 方 法 ， 
回 output 绑 定 的 输出 通道 中 发 送 内 容 ， 也 束 是 同名 为 input 的 主题 中 传递 
消息 ， 这 样 App1 中 的 input 输 入 通道 就 可 以 收 到 这 个 消息 。 同 时 ， 这 里 
还 创建 了 对 input 输 入 消息 通道 的 绑 定 。 通 过 上 面 的 配置 ， 它 会 监听 来 上 自 
output 主题 的 消息 ， 通 过 receiveFromOutput 方 法 ， 会 将 消息 内 容 输 出 。 

@EnableBinding (value={Processor.class}) 

public class App2 { 

private static Logger logger=LoggerFactory.getLogger (App2.class) ; 

Bean 














@InboundChannelAdapter (value=Processor.OUTPUT,poller=(@Poller ' 

"2000") ) 

public MessageSource<Date> timerMessageSource () { 

return () -> new GenericMessage<> (new Date () ) ; 

} 

@StreamListener (Processor.INPUT) 

public void receiveFromOutput (Object payload) { 

logger.info ("Received: "+payload) ; 

} 

} 

将 App1 和 App2 同 时 运行 起 来 ， 我 们 分 别 可 以 从 它们 的 控制 台中 看 到 
如 下 内 容 。 

eApp1l 应 用 的 控制 台 输 出 如 下 所 示 ， 它 输出 了 来 自 App2 应 用 中 定义 
的 加 input 主 题 中 轮 询 发 送 的 时 间 。 


INFO 28180---[mWYODqgqFPjxMmeg- 
1]jcom.didispace.HelljoApplication : Received: 

Wed Nov 16 08:19:16 CST 2016 

INFO 28180---[mWYODqgqFPjxMmeg- 
1jcom.didispace.HelljoApplication : Received: 

Wed Nov 16 08:19:18 CST 2016 

INFO 28180---[mWYODgFPjxMmeg- 
1]jcom.didispace.HelljoApplication : Received: 


Wed Nov 16 08:19:20 CST 2016 

e App2 应 用 的 控制 台 输 出 如 下 所 示 ， 由 于 App1l 应 用 在 打印 了 input 主 
题 中 的 消息 之 后 做 了 一 些 简 单 的 字符 串 拼 接 ， 然 后 将 拼接 后 的 字符 串 输 
而 下 面 的 输出 内 容 正 是 App2 应 用 从 output 主 题 中 获取 
和 J 消息 内 容 。 


INFO 31916---[xmrMNO7yhd8Ag- 
1lcom.didispace.HelloApplication : Received: 

From Input Channel Return-Wed Nov 16 08:19:16 CST 2016 

INFO 31916---[xmrMNO7yhd8Ag- 
1jcom.didispace.HelljoApplication : Received: 

From Input Channel Return-Wed Nov 16 08:19:18 CST 2016 

INFO 31916---[xmrMNO7yhd8Ag- 
1jcom.didispace.HelljoApplication : Received: 


From Input Channel Return-Wed Nov 16 08:19:20 CST 2016 
在 Spring Cloud Stream 中 除了 可 以 使 用 @SendTo 注 解 将 方法 返回 结果 


输出 到 消息 通道 中 ， 还 可 以 使 用 原生 注解 @ServiceActivator 的 
outputChannel 属性 配置 输出 通道 把 返回 结果 发 送 给 消息 中 间 件 。 根 据 上 
面 的 例子 ， 我 们 可 以 将 Appl1 应 用 修改 成 下 面 这样 ， 它 们 实现 的 效果 是 
一 样 的 。 

@EnableScheduling 

@EnableBinding (value={Processor.class}) 

public class Appl { 

private static Logger logger=LoggerFactory.getLogger (Appl.class) ; 

@ServiceActivator (inputChannel=Processor.INPUT,outputChannel=Pro 

public Object receiveFromInput (Object payload) { 

logger.info ("Received: "+payload) ; 

return "From Input Channel Return-"+payload; 

} 

} 


啊 应 式 编程 


在 Spring Cloud Stream 中 还 支持 使 用 基于 RxJava 的 啊 应 式 编程 来 处 理 
消 恩 的 输入 和 输出 。 与 RxJava 的 整合 使 用 同样 很 容易 ， 下 面 我 们 详细 看 
看 如 何 使 用 RxJava 实 现 上 面 消息 反馈 中 试验 的 场景 : App1l 应 用 接收 来 自 
App2 应 用 发 送 到 input 主 题 的 消息 ， 并 返回 一 条 消息 到 output 主 题 供 App2 
应 用 消 妃 输出 。 

e 在 pom.xml 中 引入 spring-cloud-stream-rxjava 依 赖 ， 有 具体 如 下 : 

<dependency> 

<groupld>org.springframework.cloud</groupld> 

<artifactId>spring-cloud-stream-rxjava</artifactId> 

<version>1.0.2.RELEASE</version> 

</dependency> 

e 改 造 App1 的 实现 ， 具 体 如 下 : 

(@@OEnableRxJavaProcessor 

public class Appl { 

private static Logger logger=LoggerFactory.getLogger (Appl.class) ; 

Bean 

public RxJavaProcessor<String,String> processor () { 

return inputStream-> inputStream.map (data->{ 

logger.info ("Received: "+data) ; 

return data; 











}) .map (data-> String.valueOf ("From Input Channel Return- 
"+data) ) ; 


} 

通过 上 面 的 改造 ， 我 们 再 次 运行 App1 和 App2 束 可 以 得 到 与 上 一 节 消 
恩 反 馈 中 的 试验 相同 的 结果 。 下 面 对 前 面 的 实现 内 容 做 一 些 说 明 。 

e 在 App1 的 类 名 上 ， 我 们 使 用 @EnableRxJavaProcessor 蔡 代 了 原来 
的 @EnableBinding (value={Processor.class} ; ， 该 注解 用 来 标识 当前 类 
中 应 该 提供 一 个 RxJavaProcessor 实 现 的 Bean。 男 外 从 其 源码 中 还 可 以 看 
到 它 自 身 就 实现 了 对 Processor 定 义 通道 的 绑 定 : 
@EnableBinding ({Processor.class}) 。 

@Target ({ElementType.TYPE}) 

@Retention (RetentionPolicy.RUNTIME) 

Documented 

QInherited 

@EnableBinding ({Processor.class}) 

@Import 〈{RxJavaProcessorConfiguration.class} ) 

public COinterface EnableRxJavaProcessor { 











， 

e 在 Appl 中 还 定义 了 一 个 RxJavaProcessor 的 实现 Bean。 在 
RxJavaProcessor 接 口中 定义 了 一 个 用 来 处 理 输入 通道 和 返回 内 容 给 输出 
通道 的 process 方法 ， 由 于 输入 输出 都 采用 了 Observable， 所 以 该 方法 只 
会 在 应 用 局 动 的 时 候 调 用 一 次 ， 用 来 设置 数据 流 。 当 有 消息 到 达 输 入 通 
道 时 ， 会 采用 RxJava 实 现 的 观察 者 模式 来 消费 和 输出 内 容 。 

public interface RxJavaProcessor<I,O> { 

Observable<O> process (Observable<I> input) ; 








} 

e 除 了 实现 上 面 的 场景 之 外 ， 通 过 利用 RxJava 的 文 持 ， 我 们 还 能 轻易 
地 实现 消 明 的 缓存 聚合 。 比 如 ， 我 们 希望 App1l 在 接收 到 5 条 消 朋 之 后 才 
将 处 理 结果 返回 给 输出 通道 ， 那 么 只 需 通过 下 面 的 改进 即 可 轻松 实现 这 
样 的 场景 : 

人 EnableRXJavaProcesSor 

public class Appl { 

Bean 

public RxJavaProcessor<String, String> processor () { 

private static Logger logger=LoggerFactory.getLogger (Appl.class) ; 

return inputStream-> inputStream.map (data->{ 


logger.info ("Received: "+data) ; 

return data; 

}) .buffer (5) .map (data-> String.valueOf ("From Input Channel 
Return-"+data) ) ; 

} 

} 

再 次 执行 App1 和 App2 应 用 ， 此 时 我 们 在 App1 应 用 中 会 得 到 一 样 的 输 
出 ， 但 是 在 App2 应 用 中 会 得 到 下 面 的 输出 : 


INFO 8796---[-maOhv-th7Raw- 
1jcom.didispace.HelljoApplication : Received: 

From Input Channel Return- 
[1479390916408,1479390918409,1479390920412,1479390922414, 

1479390924415] 

INFO 8796---[-maOhv-th7Raw- 
1jcom.didispace.HelljoApplication : Received: 

From Input Channel Return- 


[1479390926416,1479390928418,1479390930419,1479390932421, 
1479390934423|] 


消 费 组 与 消 局 分 区 


在 “核心 概念 ”一 节 中 ， 我 们 对 消费 组 和 消息 分 区 已 经 进行 了 基本 的 
J 0 

消费 组 

通常 每 个 服务 都 不 会 以 单 节点 的 方式 运行 在 生产 环境 中 ， 当 同一 个 
服务 局 动 多 个 实例 的 时 候 ， 这 些 实例 会 绑 定 到 同一 个 消息 通道 的 目标 主 
题 上 上。 默认 情况 下 ， 当 生产 者 发出 一 条 消息 到 绑 定 通道 上 ， 这 条 消息 会 
产生 多 个 副本 被 每 个 消费 者 实例 接收 和 处 理 。 但 是 在 有 些 业 务 场景 之 
下 ， 我 们 希望 生产 者 产生 的 消 明 只 被 其 中 一 个 实例 消费 ， 这 个 时 候 就 需 
要 为 这 些 消费 者 设置 消费 组 来 实现 这 样 的 功能 。 实 现 的 方式 非常 简单 ， 
只 需 在 服务 消费 者 端 设置 Spring.cloud.stream.bindings.input.group 属 性 即 
可 ， 比 如 可 以 像 下 面 这 样 实现 。 

e 可 以 先 实 现 一 个 消费 者 应 用 SinkReceiver， 实 现 greetings 主 题 上 的 输 
入 通道 绑 定 ， 它 的 实现 如 下 : 

@EnableBinding (value={Sink.class}) 

public class SinkReceiver { 

private static Logger 
































logger=LoggerFactory.getLogger (SinkReceiver.class) ; 
@StreamListener (Sink.INPUT) 
public void receive (User user) { 
logger.info ("Received: "+user) ; 


} 


} 

e 为 了 将 SinkReceiver 的 输入 通道 目标 设置 为 greetings 主题 ， 以 及 将 
该 服务 的 实例 设置 为 同一 个 消费 组 ， 可 做 如 下 设置 : 

spring.cloud.stream.bindings.input.group=Service-A 

spring.cloud.stream.bindings.input.destination=greetings 

通过 spring.cloud.stream.bindings.input.group 属 性 指定 了 该 应 用 实例 都 
属于 Service-A 消费 组 ， 而 spring.cloud.stream.bindings.input.destination 
属性 则 指定 了 输入 通道 对 应 的 主题 名 。 

e 完 成 了 消息 消费 者 应 用 之 后 ， 我 们 再 来 实现 一 个 消息 生产 者 应 用 
SinkSender， 有 具体 如 下 : 

@EnableBinding (value={Source.class}) 

public class SinkSender { 





private static Logger 
logger=LoggerFactory.getLogger (SinkSender.class) ; 
Bean 


@InboundChannelAdapter (value=Source.OUTPUT,poller=@Poller (fi: 
public MessageSource<String> timerMessageSource () { 


return () -> new GenericMessage<> (" 
{\"name\":\"didi\",\"age\":30}") ; 
} 


| 

e 为 消息 生产 者 SinkSender 做 一 些 设置 ， 让 它 的 输出 通道 绑 定 目标 
也 指向 greetings 主 题 ， 具 体 如 下 : 

spring.cloud.stream.bindings.output.destination=greetings 

到 这 里 ， 对 于 消费 分 组 的 示例 束 完 成 了 。 分 别 运行 上 面 实现 的 生产 
者 与 消费 者 ， 其 中 消费 者 我 们 局 动 多 个 实例 。 通 过 控制 合 ， 可 以 发 现 ， 
每 个 生产 者 发 出 的 消息 会 被 局 动 的 消费 者 以 轮 询 的 方式 进行 接收 和 输 


出 。 

消息 分 区 

通过 消费 组 的 设置 ， 虽 然 我 们 已 经 能 够 在 多 实例 环境 下 ， 保 证 同一 
消息 只 被 一 个 消费 者 实例 进行 接收 和 人 处理， 但 是 ， 对 于 一 些 特殊 场景 ， 
除了 要 保证 单一 实例 消费 之 外 ， 还 希望 那些 具备 相同 特征 的 消息 都 能 够 











被 同一 个 实例 进行 消费 。 这 时 候 我 们 就 需要 对 消息 进行 分 区 处 理 。 

在 Spring Cloud Stream 中 实现 消息 分 区 非常 简单 ， 我 们 对 消费 组 示例 
做 一 些 配置 修改 就 能 实现 ， 有 具体 如 下 所 示 。 

e 在 消费 者 应 用 SinkReceiver 中 ， 对 配置 文件 做 一 些 修改 ， 具 体 如 
下 : 


spring.cloud.stream.bindings.input.group=Service-A 

spring.cloud.stream.bindings.input.destination=greetings 

Spring.cloud.stream.bindings.input.consumer.partitioned=true 

Spring.cloud.stream.instanceCount=2 

Spring.cloud.stream.instanceIndex=0 

从 上 面 的 配置 中 ， 我 们 可 以 看 到 增加 了 下 面 这 三 个 参数 。 

1.spring.cloud.stream.bindings.input.consumer.partitioned: 通过 该 参数 
开局 消费 者 分 区 功能 。 

2.Spring.cloud.stream.instanceCount: 该 参数 指定 了 当前 消费 者 的 总 实 
例 数 量 。 

3.spring.cloud.stream.instanceIndex: 该 参数 设置 当前 实例 的 索引 号 ， 
从 0 开始 ， 最 大 值 为 Spring.cloud.stream.instanceCount 参 数 -1。 试 验 的 时 候 
动 多 个 实例 ， 可 以 通过 运行 参数 来 为 不 同 实例 设置 不 同 的 索引 


值 。 

e 在 生产 者 应 用 SinkSender 中 ， 对 配置 文件 也 做 一 些 修改 ， 具 体 如 下 
所 示 。 

spring.cloud.stream.bindings.output.destination=greetings 

spring.cloud.stream.bindings.output.producer.partitionKeyExpression=pay 

spring.cloud.stream.bindings.output.producer.partitionCount=2 

从 上 面 的 配置 中 ， 我 们 可 以 看 到 增加 了 下 面 这 两 个 参数 。 

1.spring.cloud.stream.bindings.output.producer.partitionKeyExpression: 
通过 该 参数 指定 了 分 区 键 的 表达 式 规 则 ， 我 们 可 以 根据 实际 的 输出 消 奶 
规则 配置 SpEL 来 生成 合适 的 分 区 键 。 

2.spring.cloud.stream.bindings.output.producer.partitionCount: 该 参数 
指定 了 消息 分 区 的 数量 。 

到 这 里 消息 分 区 配置 就 完成 了 ， 我 们 可 以 再 次 局 动 这 两 个 应 用 ， 同 
时 启动 多 个 消费 者 。 但 需要 注意 的 是 ， 要 为 消费 者 指定 不 同 的 实例 索引 
号 ， 这 样 当 同一 个 消息 被 上 友 送 给 消费 组 时 ， 可 以 发 现 只 有 一 个 消费 实例 
在 接收 和 处 理 这 些 相 同 的 消息 。 


消息 类 型 

















Spring Cloud Stream 为 了 让 开发 者 能 够 在 消息 中 声明 它 的 内 容 类 型 ， 
在 输出 消息 中 定义 了 一 个 默认 的 头 信息 : contentType。 对 于 那些 不 直接 
支持 头 信 息 的 消息 中 间 件 ，Spring Cloud Stream 提供 了 自己 的 实现 机 
制 ， 它 会 在 消息 发 出 前 自动 将 消息 包装 进 它 自 定义 的 消息 封装 格式 中 ， 
并 加 入 头 信息 。 而 对 于 那些 自身 藉 支持 头 信息 的 消 筷 中 间 件 ，Spring 
Cloud Stream 构 建 的 服务 可 以 接收 并 处 理 来 自 非 Spring Cloud Stream 构 建 
但 包含 符合 规范 头 信 息 的 应 用 程序 发 出 的 消息 。 

Spring Cloud Stream 人 允许 使 用 spring.cloud.stream.bindngs. 
<channelName>.content-type 属 性 以 声明 式 的 配置 方式 为 绑 定 的 输入 和 输 
出 通道 设置 消息 内 容 的 类 型 。 此 外 ， 原 生 的 消息 类 型 转换 器 依然 可 以 轻 
松 地 用 于 我 们 的 应 用 程序 。 目 前 ，Spring Cloud Stream 中 自 带 支持 了 以 
下 几 种 常用 的 消息 类 型 转换 。 

eJSON 与 POJO 的 互相 转换 。 

eJSON 与 org.springframework.tuple.Tuple 的 互相 转换 。 

eObject 与 byte[l] 的 互相 转换 。 为 了 实现 远程 传输 序列 化 的 原始 字 
节 ， 应 用 程序 需要 发 送 byte 类 型 的 数据 ， 或 是 通过 实现 Java 的 序列 化 
接口 来 转换 为 字 节 (Object 对 象 必须 可 序列 化 ) 。 

eString 与 byte[] 的 互相 转换 。 

eObject 问 纯 文 本 的 转换 : Object 需 要 实现 toString() 方法 。 

上 面 所 指 的 JSON 类 型 可 以 表现 为 一 个 byte 类 型 的 数组 ， 也 可 以 是 
一 个 包含 有 效 JSON 内 容 的 字符 串 。 另 外 ，Object 对 象 可 以 由 JSON、Pbyte 
数组 或 者 字符 串 转 换 而 来 ， 但 是 在 转换 为 JSJON 的 时 候 总 是 以 字符 串 的 
形式 返回 。 

MIME 类 型 

在 Spring Cloud Stream 中 定义 的 content-type 属 性 采用 了 Media Type， 
即 Internet Media Type (互联 网 媒体 类 型 )， 也 被 称 为 MIME 类 型 ， 常 见 
的 有 application/json、text/plain; ”charset=UTF-8， 相 信 接 触 过 HTTP 的 工 
程 师 们 对 这 些 类 型 都 不 会 感到 陌生 。MIME 类 型 对 于 标示 如 何 转换 为 
String 或 byte[] 非 常 有 用 。 并 且 ， 我 们 还 可 以 使 用 MIME 类 型 格式 来 表示 
Java ”类 型 ， 只 需要 使 用 带 有 类 型 参数 的 一 般 类 型 : application/x-java- 
object。 比 如 ， 我 们 可 以 使 用 application/x-javaobject; type=java.util.Map 
来 表示 传输 的 是 一 个 java.util.Map 对 象 ， 或 是 使 用 application/x-java- 
object; type=com.didispace.User 来 表示 传输 的 是 一 个 com.didispace.User 
对 象 ， 除 此 之 外 ， 更 重要 的 是 ， 它 还 提供 了 自 定 义 的 MIME 类 型 ， 比 如 
通过 application/x-spring-tuple 来 指定 Spring 的 Tuple 类 型 。 

在 Spring Cloud Stream 中 默认 提供 了 一 些 可 以 开 箱 即 用 的 类 型 转换 
器 ， 具 体 如 下 表 所 示 。 























消息 类 型 的 转换 行为 只 会 在 需要 进行 转换 时 才 被 执行 ， 比 如 ， 当 服 
务 模块 产生 了 一 个 头 信 息 为 application/json 的 XML 字符 串 消 息 ，Spring 
Cloud Stream 是 不 会 将 该 XML 字符 串 转 换 为 JSJON 的 ， 这 是 因为 该 模块 
内 容 已 经 是 一 个 字符 串 类 型 了 ， 上 所 以 它 并 不 会 将 其 做 进一步 的 转 





另外 需要 注意 的 是 ，Spring Cloud Stream 虽 然 同 时 文 持 输入 通道 和 输 
出 通道 的 消息 类 型 转换 ， 但 还 是 推荐 开发 者 尽量 在 输出 通道 中 做 消息 转 
换 。 因 为 对 于 输入 通道 的 消费 者 来 襄 ， 当 目标 是 一 个 POJO 的 时 候 ， 使 
用 @StreamListener 注 解 是 能 够 文 持 自动 对 其 进行 转换 的 。 

Spring Cloud Stream 除 了 提供 上 面 这 些 开 箱 即 用 的 转换 器 之 外 ， 还 文 
持 开 发 者 自 定义 的 消息 转换 器 。 这 使 得 我 们 可 以 使 用 任意 格式 (包括 二 
进 制 ) 的 数据 进行 发 送 和 接收 ， 并 且 将 这 些 数据 与 特定 的 contentType 相 
关联 。 在 应 用 启用 的 时 候 ，Spring Cloud Stream 会 将 所 有 
org.Springframework.messaging.converter.MessageConverter 接 口 实现 的 自 
定义 转换 器 以 及 默认 实现 的 那些 转换 器 都 加 载 到 消息 转换 工厂 中 ， 以 提 
供给 消息 处 理 时 使 用 。 
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在 “核心 概念 ”一 玉 中 ， 我 们 已 经 简单 介绍 过 Binder 绑 定 露 的 基本 概念 
和 作用 : 它 是 定义 在 应 用 程序 与 消息 中 间 件 之 问 的 抽象 层 ， 用 来 屏蔽 消 
恩 中 间 件 对 应 用 的 复杂 性 ， 并 提供 简单 而 统一 的 操作 接口 给 应 用 程序 使 
用 。 在 本 节 中 ， 我 们 将 详细 介绍 绑 定 器 背后 的 细节 和 行为 。 


绑 定 右 SPI 


绑 定 器 SPI 涵盖 了 一 套 可 插 拔 的 用 于 连接 外 部 中 间 件 的 实现 机 制 ， 
其 中 包含 了 许多 接口 、 开 箱 即 用 的 实现 类 以 及 发 现 策略 等 内 容 。 其 中 ， 
ee 

public interface Binder<T,C extends ConsumerProperties,P extends 

ProducerProperties> { 

Binding< 工 > bindConsumer (String name,String group,T 
inboundBindTarget,C 

consumerProperties ) ; 

Binding<T> bindProducer (String name,T outboundBindTarget,P 

producerProperties) ; 


} 

当 应 用 程序 对 输入 和 输出 通道 进行 绑 定 的 时 候 ， 实 际 上 就 是 通过 该 
接口 的 实现 来 完成 的 。 

e 问 滑 思 通道 肥 送 数据 的 生产 者 调用 bindProducer 方法 来 绑 定 输出 通 

道 时 ， 第 一 个 参数 代表 了 发 往 消息 中 间 件 的 目标 名 称 ， 第 二 个 参数 代表 
了 发 送 消息 的 本 地 通道 实例 ， 第 三 个 参数 是 用 来 创建 通道 时 使 用 的 属性 
配置 〈 比 如 分 区 键 的 表达 式 等 ) 。 

。 从 消息 通道 接收 数据 的 消费 者 调用 bindConsumer 方法 来 绑 定 输 入 
通道 时 ， 第 一 个 参数 代表 了 接收 注 因 中间 件 的 目标 名 称 ， 第 二 个 参数 代 
表 了 消费 组 的 名 称 〈 如 果 多 个 消费 者 实例 使 用 相同 的 组 名 ， 则 消息 将 对 
这 些 消费 者 实例 实现 负 物 作 ， 每 个 生产 者 发 的 消息 只 会 组 内 = 
消费 者 实例 接收 和 处 理 ) ， 第 三 个 参数 代表 了 接收 消息 的 本 地 通 
例 ， 第 四 个 参数 是 用 来 创建 通道 时 使 用 的 属性 配置 。 

男 外 ， 从 Binder 的 定义 中 ， 我 们 还 可 以 知道 Binder 是 一 个 参数 化 并 且 
可 扩展 的 接口 。 


























e 对 于 输入 与 输出 的 绑 定 类 型 ， 在 1.0 版 本 中 仅 支 持 MessageChannel， 
但 是 在 接口 中 通过 泛 型 定义 ， 所 以 在 未 来 可 以 对 其 进行 扩展 。 

e 对 于 属性 配置 也 提供 了 可 扩展 的 定义 ， 我 们 可 以 为 特定 的 Binder 以 
类 型 安全 的 方式 来 补充 一 些 特有 的 属性 。 

一 个 典型 的 Binder 绑 定 器 实现 一 般 包含 以 下 内 容 。 

e 一 个 实现 Binder 接 口 的 类 。 
ge 用 来 创建 连接 消息 中 间 件 的 基础 结构 使 用 

I 实例 。 

e 一 个 或 多 个 能 够 在 classpath 下 的 META-INEF/spring.binders 路 径 找到 
的 绑 定 右 定 义 文件 。 比 如 我 们 可 以 在 spring-cloud-starter-stream-rabbit 中 
找到 该 文件 ， 该 文件 中 存储 了 当前 绑 定 器 要 使 用 的 自动 化 配置 类 的 路 
径 : 

rabbit:\ 

org.springframework.cloud.stream.binder.rabbit.config.RabbitServiceAutc 
ation 


且 动 化 配置 


Spring Cloud Stream 通 过 绑 定 器 SPI 的 实现 将 应 用 程序 逻辑 上 的 输入 
输出 通道 连接 到 物理 上 的 消 明 中 间 件 。 消 奶 中 间 件 之 间 通 常 都 会 有 或 多 
或 少 的 差异 性 ， 所 以 为 了 适 配 不 同 的 消息 中 间 件 ， 需 要 为 它们 实现 各 自 
独 有 的 绑 定 器 。 目 前 ，Spring Cloud Stream 中 默认 实现 了 对 RabbitMQ、 
Kafka 的 绑 定 器 ， 在 上 面 的 示例 中 我 们 引入 的 Spring-cloud-starterstream- 
rabbit 依 赖 中 就 包含 了 RabbitMQ 的 绑 定 器 spring-cloud-stream- 
binderrabbit 。 

默认 情况 下 ，Spring Cloud Stream 也 遵循 Spring Boot 自动 化 配置 的 
特性 。 如 有 果 在 classpath 中 能 够 找到 单个 绑 定 器 的 实现 ， 那 么 Spring Cloud 
Stream 会 自动 加 载 它 。 而 我 们 在 classpath 中 引入 绑 定 器 的 方法 也 非常 简 
只 需要 在 pom.xml 中 增加 对 应 消 妃 中 间 件 的 绑 定 绒 依赖 即 可 ， 比 

0: 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-stream-binder-rabbit</artifactId> 

</dependency> 

如 果 使 用 Kafka， 则 引入 : 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 


<artifactId>spring-cloud-stream-binder-kafka</artifactId> 
</dependency> 


已 之 二 局 


当 应 用 程序 的 classpath 下 存在 多 个 绑 定 器 时 ，Spring Cloud Stream 在 
为 消 轧 通道 做 绑 定 操作 时 ， 无 法 判断 应 该 使 用 哪个 具体 的 绑 定 器 ， 所 以 
我 们 需要 为 每 个 输入 或 输出 通道 指定 具体 的 绑 定 峰 。 

我 们 在 一 个 应 用 程序 中 使 用 多 个 绑 定 器 时 ， 往 往 其 中 一 个 绑 定 器 会 
是 主要 使 用 的 ， 而 第 二 个 可 能 是 为 了 适应 一 些 特殊 要 求 〈( 比 如 性 能 等 原 
因 ) 。 我 们 可 以 先 通过 设置 默认 绑 定 堪 来 为 大 部 分 的 通道 设置 绑 定 器 。 
比如 ， 使 用 RabbitMQ 设 置 默认 绑 定 器 : 

spring.cloud.stream.defaultBinder=rabbit 

在 设置 了 默认 绑 定 圳 之 后 ， 再 为 其 他 一 些 少数 的 消 恩 通道 单独 设置 
纤 定 3 比 如 3 

spring.cloud.stream.bindings.input.binder=kafka 

需要 注意 的 是 ， 上 面 我 们 设置 参数 时 用 来 指定 具体 绑 定 器 的 值 并 不 
是 消 忠 中 间 件 的 名 称 ， 而 是 在 每 个 绑 定 兹 实现 的 META- 
INF/spring.binders 文 件 中 定义 的 标识 一 个 绑 定 器 实现 的 标识 可 以 定义 
多 个 ， 以 逗号 分 隔 ) ， 所 以 上 面 配置 的 rabbit 和 kafka 分 别 来 自 于 各 目的 
配置 定义 ， 它 们 的 具体 内 容 如 下 所 示 : 

rabbit:\ 

org.springframework.cloud.stream.binder.rabbit.config.RabbitServiceAutc 
ation 

kafka:\ 

org.Springframework.cloud.stream.binder.kafka.config.KafkaBinderConfil 

另外 ， 当 需要 在 一 个 应 用 程序 中 使 用 同一 类 型 不 同 环境 的 绑 定 峰 
时 ， 我 们 也 可 以 通过 配置 轻松 实现 通道 绑 定 。 比 如 ， 当 需要 连接 两 个 不 
同 的 RabbitMQ 实例 的 时 候 ， 可 以 参照 如 下 配置 : 

Spring.cloud.stream.bindings.input.binder=rabbit1 

Spring.cloud.stream.bindings.output.binder=rabbit2 

spring.cloud.stream.binders.rabbit1.type=rabbit 

Spring.cloud.stream.binders.rabbit1.environment.Spring.rabbitmq.host=19. 

Spring.cloud.stream.binders.rabbit1.environment.Spring.rabbitmgq.port=56， 

Spring.cloud.stream.binders.rabbit1.environment.Spring.rabbitmq.usernam 

spring.cloud.stream.binders.rabbitl.environment.spring.rabbitmq.passwor 

spring.cloud.stream.binders.rabbit2.type=rabbit 




















Spring.cloud.stream.binders.rabbit2.environment.Spring.rabbitmq.host=19. 

Spring.cloud.stream.binders.rabbit2.environment.Spring.rabbitmq.port=56， 

Spring.cloud.stream.binders.rabbit2.environment.Spring.rabbitmq.usernam 

spring.cloud.stream.binders.rabbit2.environment.spring.rabbitmq.passwor' 

从 上 面 的 配置 中 ， 我 们 可 以 看 到 对 于 输入 输出 通道 指定 的 绑 定 需 采 
用 了 显 式 别 名 的 配置 方式 ， 其 中 input 通 道 的 绑 定 指定 了 名 为 rabbit1 的 配 
置 ， 而 output 通 道 的 绑 定 指定 了 名 为 rabbit2 的 配置 。 当 采用 显 式 配置 方 
式 时 会 自动 禁用 默认 的 绑 定 吉 配置 ， 所 以 当 定 义 了 显 式 配置 别名 后 ， 对 
于 这 些 绑 定 器 的 配置 需要 通过 spring.cloud.stream.binders. 
<configurationName> 属 性 来 进行 设置 。 对 于 绑 定 器 的 配置 主要 有 下 面 4 
个 参数 。 

espring.cloud.stream.binders.<configurationName>.type 指定 了 绑 定 右 
的 类 型 ， 可 以 是 rabbit、kafak 或 者 其 他 目 定 义 绑 定 喜 的 标识 名 ， 绑 定 句 
标识 名 的 定义 位 于 绑 定 器 的 META-INEF/spring.binders 文 件 中 。 

espring.cloud.stream.binders.<configurationName>.environment 

参数 可 以 直接 用 来 设置 各 绑 定 器 的 属性 ， 默 认为 空 

espring.cloud.stream.binders.<configurationName>.inheritEnvir onment 
参数 用 来 配置 当前 绑 定 器 是 否 继承 应 用 程序 自身 的 环境 配置 ， 默 认为 
true。 

espring.cloud.stream.binders.<configurationName>.defaultCandi date 参 
数 用 来 设置 当前 绑 定 费 配 置 是 否 被 视 为 默认 绑 定 强 的 候选 项 ， 默 认为 
true。 


当 需 要 让 当前 配置 不 影响 默认 配置 时 ， 可 以 将 该 属性 设置 为 false。 


RabbitMQ 与 Kafka 绑 定 器 


在 之 前 的 章节 中 我 们 多 次 提 到 ，Spring Cloud Stream 自 身 就 提供 了 对 
RabbitMQ 和 Kafka 的 绑 定 器 实现 。 由 于 RabbitMQ 和 Kafka 自身 的 实现 
结构 有 所 不 同 ， 理 解 绑 定 喜 实 现 与 消息 中 间 件 目 有 概念 之 间 的 对 应 关 
系 ， 对 于 正确 使 用 绑 定 器 和 消息 中 间 件 会 有 非常 大 的 帮助 。 下 面 束 来 分 
别 说 说 RabbitMQ 与 Kafka 的 绑 定 器 是 如 何 使 用 消息 中 间 件 中 不 同 概念 
来 实现 消息 的 生产 与 消费 的 。 

eRabbitMQ 绑 定 器 : 在 RabbitMQ 中 ， 通 过 Exchange 交 换 右 来 实现 
Spring Cloud Stream 的 主题 概念 ， 所 pi 奶 通 道 的 输入 输出 目标 映射 了 
一 个 具体 的 Exchange 交 换 嚣 。 而 对 于 每 个 消费 组 ， 则 会 为 对 应 的 
Exchange 交 换 器 绑 定 一 个 Queue 队 列 进行 消息 收发 。 

eKafka 绑 定 器 : 由 于 Kafka 自 身 就 有 Topic 概 念 ， 所 以 Spring Cloud 





























Stream 的 主题 直接 采用 了 Kafka 的 Topic 主 题 概 念 ， 每 个 消费 组 的 通道 目 
标 都 会 直接 连接 Kafka 的 主题 进行 消息 收发 。 





本 0 兽 详 解 


在 Spring Cloud Stream 中 对 绑 定 通道 和 绑 定 器 提供 了 通用 的 属性 配置 
项 ， 一 些 绑 定 器 还 允许 使 用 附加 属性 来 对 消息 中 间 件 的 一 些 独 有 特性 进 
行 配置 。 这 些 属 性 的 配置 可 以 通过 Spring Boot 支 持 的 任何 配置 方式 来 进 
行 ， 包 括 使 用 环境 变量 、YAML 或 者 properties 配 置 文件 等 。 


基础 配置 
下 表 是 Spring Cloud Stream 应 用 级 别 的 通用 基础 属性 ， 这 些 属性 都 以 


spring.cloud.stream. 为 前 级 。 








绑 定 通道 配置 
对 于 绑 定 通道 的 属性 配置 ， 在 之 前 的 示例 中 已经 有 过 一 些 介绍 ， 这 
些 配 置 可 以 在 属性 文件 中 通过 spring.cloud.stream.bindings. 





<channelName>.<property>=<value> 格 式 的 参数 来 进行 设置 。 其 中 
<channelName> 代 表 在 绑 定 接口 中 定义 的 通道 名 称 ， 比 如 ，Sink 中 的 
input、Source 中 的 output。 

由 于 绑 定 通道 分 为 输入 通道 和 输出 通道 ， 所 以 在 绑 定 通道 的 配置 中 
癌 不 同 通 道 类 型 的 配置 : 通用 配置 、 消 费 者 配置 、 生 产 者 
配置 。 

在 下 面 介 绍 各 有 具体 配置 属性 时 将 省 略 。 spring.cloud.stream.bindings. 
<channelName>. 前 级 ， 但 在 实际 使 用 的 时 候 记 得 使 用 完整 的 参数 名 称 进 
行 配置 。 

通用 配置 

对 于 绑 定 通道 的 通用 配置 ， 它 们 既 适 用 于 输入 通道 ， 也 适用 于 输出 
通道 ， 它 们 通过 spring.cloud.stream.bindings.<channelName>. 前 绥 来 进行 
设置 ， 具体 可 配置 的 属性 如 下 表 所 示 。 


消费 者 配置 
下 面 这些 配 置 仅 对 输入 通道 的 绑 定 有 效 ， 它 们 以 


spring.cloud.stream.bindings.<channelName>.consumer. 格 式 作 为 前 级 。 


生产 者 配置 

















下 面 这 些 配 置 仅 对 输出 通道 的 绑 定 有 效 ， 它 们 以 
spring.cloud.stream.bindings.<channelName>.producer. 格 式 作 为 前 绥 。 


续 表 


心 -> 二 驻 





由 于 Spring Cloud Stream 目前 只 实现 了 对 RabbitMQ 和 Kafka 的 绑 定 
器 ， 所 以 对 于 绑 定 器 的 属性 配置 主要 是 针对 这 两 个 中 间 件 。 同 时 因为 这 
两 个 中 间 件 自 映 结构 的 不 同 ， 所 以 会 有 不 同 的 附加 属性 来 配置 各 自 的 一 
些 特殊 功能 和 基础 设施 。 

RabbitMQ 配 置 

RabbitMQ 绑 定 器 的 配置 同 绑 定 通道 的 配置 一 样 ， 分 为 三 种 不 同类 
型 : 通用 配置 、 消 费 者 配置 以 及 生产 者 配置 。 

通用 配置 

由 于 ”RabbitMQ ” 绑 定 器 默认 使 用 了 Spring Boot 的 
ConnectionFactory， 所 以 RabbitMQ 绑 定 吉 支持 在 Spring Boot 中 的 配置 选 
项 ， 它 们 以 spring.rabbitmgq. 为 前 级 。 在 之 前 的 示例 中 ， 我 们 使 用 这 些 配 
置 来 指定 具体 的 ”RabbitMQ 地址、 端口 、 用 户 信息 等 ， 更 多 配置 可 见 
Spring Boot 文 档 中 对 RabbitMQ 文 持 的 章节 内 容 ， 或 是 通过 spring- 
bootstarter-amqp 模 块 中 RabbitProperties 类 的 源码 来 查看 。 

在 Spring Cloud Stream 对 RabbitMQ 实 现 的 绑 定 器 中 主要 有 下 面 几 个 
属性 ， 它 们 都 以 spring.cloud.stream.rabbit.binder. 为 前 级 。 这 些 属性 可 以 
在 
org.Springframework.cloud.stream.binder.rabbit.config.RabbitBinderConfigur 
中 找到 它们 。 

消费 者 配置 

下 面 这 些 配 置 仅 对 RabbitrMQ 输 入 通道 的 绑 定 有 效 ， 它 们 以 


spring.cloud.stream.rabbit.bindings.<channelName>.consumer. 格 式 作为 前 
级 。 


























生产 者 配置 


下 面 这 些 配 置 仅 对 RabbitMQ 输 出 通道 的 绑 定 有 效 ， 它 们 以 
spring.cloud.stream.rabbit.bindings.<channelName>.producer. 格 式 作 为 前 
级 。 


Kafka 配 置 

Kafka 绑 定 器 的 配置 在 类 别 上 与 RabbitMQ 一 样 ， 分 为 三 种 不 同类 
型 : 通用 配置 、 消 费 者 配置 以 及 生产 者 配置 。 但 是 由 于 RabbitMQ 与 
Kafka 自身 有 一 些 差 异 ， 所 以 它们 的 配置 也 不 一 样 。 

通用 配置 

Spring Cloud Stream 实现 的 Kafka 绑 定 器 包含 下 面 这 些 通用 配置 ， 它 
们 都 以 Spring.cloud.stream.kafka.binder. 为 前 绥 。 


续 表 


消费 者 配置 | 

下 面 这 些 配 置 仅 对 Kafka 输入 通道 的 绑 定 有 效 ， 它 们 以 
spring.cloud.stream.kafka.bindings.<channelName>.consumer. 格 式 作 为 前 
级 。 














生产 者 配置 | 

下 面 这 些 配 置 仅 对 Kafka 输出 通道 的 绑 定 有 效 ， 它 们 以 
spring.cloud.stream.kafka.bindings.<channelName>.producer. 格 式 作为 前 
级 。 


续 表 


第 11 章 ” 分 布 式 服务 跟踪 : Sprin 
Cloud Sleuth 


通过 之 前 各 章节 介绍 的 Spring Cloud 组 件 ， 实 际 上 我 们 已 经 能 够 通过 
使 用 它们 搭建 起 一 个 基础 的 微服 务 架构 系统 来 实现 业务 需求 了 。 但 是 ， 
随 着 业务 的 发 展 ， 系 统 规模 也 会 变 得 越 来 越 大 ， 各 微服 务 间 的 调用 关系 
也 变 得 越 来 越 错综复杂 。 通 常 一 个 由 客户 端 发 起 的 请 求 在 后 端 系统 中 会 
经 过 多 个 不 同 的 微服 务 调用 来 协同 产生 最 后 的 请 求 结 果 ， 在 复杂 的 微服 
务 架 构 系 统 中 ， 几 乎 每 一 个 前 端 请 求 都 会 形成 一 条 复杂 的 分 布 式 服务 调 
用 链 路 ， 在 每 条 链 路 中 任何 一 个 依赖 服务 出 现 延 迟 过 高 或 错误 的 时 候 都 
有 可 能 引起 请 求 最 后 的 失败 。 这 时 候 ， 对 于 每 个 请 求 ， 全 链 路 调用 的 跟 
踪 就 变 得 越 来 越 重 要 ， 通 过 实现 对 请 求 调用 的 跟踪 可 以 帮助 我 们 快速 发 
现 错误 根源 以 及 监控 分 析 每 条 请 求 链 路 上 的 性 能 瓶颈 等 。 

针对 上 面 所 述 的 分 布 式 服务 跟踪 问题 ，Spring Cloud Sleuth 提供 了 一 

完整 的 解决 方案 。 在 本 章 中 ， 我 们 将 详细 介绍 如 何 使 用 Spring Cloud 

Sleuth 来 为 微服 务 架 构 增 加 分 布 式 服务 跟踪 的 能 力 。 




















] 束 My 
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在 介绍 各 种 概念 与 原理 之 前 ， 我 们 先 通 过 实现 一 个 简单 的 示例 ， 为 
存在 服务 调用 的 应 用 增加 一 些 Sleuth 的 配置 以 实现 基本 的 服务 跟踪 功 
能 ， 以 此 来 对 Spring Cloud Sleuth 有 一 个 初步 的 了 解 ， 随 后 再 逐步 展开 ， 
介绍 实现 过 程 中 的 各 个 细 市 。 


准备 工 








在 引入 Sleuth 之 前 ， 我 们 先 按照 之 前 章节 学 习 的 内 容 来 做 一 些 准备 工 
作 ， 构 建 一 些 基础 的 设施 和 应 用 。 

e 服 务 注册 中 心 : eureka-server， 这 里 不 做 袭 述 ， 直 接 使 用 之 前 构建 
的 工程 即 可 。 

e 微 服务 应 用 : trace-1， 实 现 一 个 REST 接 口 /trace-1， 调 用 该 接口 后 
将 触发 对 trace-2 应 用 的 调用 。 具 体 实 现 如 下 所 述 。 

加 创建 一 个 基础 的 Spring Boot 应 用 ， 在 pom.xml 中 增加 下 面 的 依赖 : 

<parent> 

<groupId>org.Springframework.boot</groupId> 

<artifactId>spring-boot-starter-parent</artifactId> 

<version>1.3.7.RELEASE</version> 

<relativePath/> 

</parent> 

<dependency> 

<groupId>org.Springframework.boot</groupId> 

<artifactId>spring-boot-starter-web</artifactId> 

</dependency> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-eureka</artifactId> 

</dependency> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-ribbon</artifactId> 

</dependency> 

<dependencyManagement> 


<dependencies> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-dependencies</artifactId> 

<version>Brixton.SR5</version> 

<type>pom</type> 

<scope>import</scope> 

</dependency> 

</dependencies> 

</dependencyManagement> 

茵 创建 应 用 主 类 ， 实 现 /trace-1 接 口 ， 并 使 用 RestTemplate 调用 trace- 
2 应 用 的 接口 。 具 体 如 下 : 

(DRestController 

(EnableDiscoveryCjlient 

SpringBootApplication 

public class Trace Application { 

private final Logger logger=Logger.getLogger (getClass () ) ; 

Bean 

(LoadBalanced 

RestTemplate restTemplate () { 

return new RestTemplate (); 

} 

@RequestMapping (value="/trace-1",method=RequestMethod.GET) 

public String trace () { 

logger.info ("===call trace-1===") ; 


return restTemplate () .getForEntity ("http://trace-2/trace- 
2",String.class) .getBody (); 
} 


public static void main (String[]args) { 
SpringApplication.run (TraceApplication.class,args) ; 


} 

国人 在 application.properties 中 ， 将 eureka.client.serviceUrl.defaultZone 参 
数 指向 eureka-server 的 地 址 ， 具 体 如 下 : 

spring.application.name=trace-1 

server.port=9101 

eureka.client.serviceUTrl.defaultZone=http://localhost:1111/eureka/ 


e 微 服务 应 用 : trace-2， 实 现 一 个 REST 接 口 /trace-2， 供 trace-1 调 用 。 
具体 实现 如 下 所 示 。 

国 他 | 建 一 个 基础 的 Spring Boot 应 用 ，pom.xml 中 的 依赖 与 trace-1 相 
同 。 

重创 建 应 用 主 类 ， 并 实现 /trace-2 接 口 ， 具 体 实 现 如 下 : 

(DRestController 

@OEnableDiscoveryClient 

SpringBootApplication 

public class TraceApplication { 

private final Logger logger=Logger.getLogger (getClass () ) ; 

@RequestMapping (value="/trace-2",method=RequestMethod.GET) 

public String trace () { 

logger.info ("===<call trace-2>===") ; 

return "Trace"; 

} 

public static void main (String[largs) { 

SpringApplication.run (TraceApplication.class,args) ; 

} 

} 

国 在 application.properties 中 ， 将 eureka.client.serviceUrl.defaultZone 参 
数 指 癌 eureka-server 的 地 址 ， 另 外 还 需要 设置 不 同 的 应 用 名 和 端口 号 ， 

有 具体 如 下 : 

Spring.application.name=trace-2 

server.port=9102 

eureka.client.serviceUTrl.defaultZone=http://localhost:1111/eureka/ 

在 实现 了 上 面 的 内 容 之 后 ， 我 们 可 以 将 eureka-server、trace-1、 
trace-2 三 个 应 用 都 启动 起 来 ， 并 通过 postman 或 curl 等 工具 来 对 trace-1 
的 接口 发 送 请 求 http://localhost:9101/trace-1。 可 以 得 到 返回 值 Trace， 同 
时 还 能 在 它们 的 控制 台中 分 别 获得 下 面 的 输出 : 

--trace-1 

INFO 25272---[nio-9101-exec- 
2]ication$$EnhancerBySpringCGLIB$$36e12c68 : 

===<Ccall trace-1>=== 

--trace-2 

INFO 7136---[nio-9102-exec- 
lljication$$EnhancerBySpringCGLIB$$52a02f0b :===<call 

trace-2>=== 





实现 跟踪 


在 完成 了 准备 工作 之 后 ， 楼 下 来 我 们 开始 进行 本 重 的 主题 内 容 ， 为 
上 面 的 trace-1 和 trace-2 添 加 服务 跟踪 功能 。 通过 Spring Cloud Sleuth 的 封 
装 ， 我 们 为 应 用 增加 服务 跟 踩 能 力 的 操作 非常 简单 ， 只 需 在 trace-1 和 
trace-2 的 pom.xml 依赖 管理 中 增加 spring-cloud-starter-sleuth 依 赖 即 可 ， 
具体 如 下 : 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-sleuth</artifactId> 

</dependency> 

到 这 里 ， 实 际 上 我 们 已 经 为 trace-1 和 trace-2 实 现 服 务 跟踪 做 好 了 基础 
的 准备 ， 重 启 。” trace-1 和 ”trace-2， 再 对 ”trace-1 的 接口 发 送 请 求 
http://localhost:9101/trace-1。 此 时 ， 我 们 可 以 从 它们 的 控制 台 输 出 中 舌 
探 到 Sleuth 的 一 些 端倪 。 

--trace-1 

INFO[trace-1,f410ab57afd5c145,a9f2118fa2019684,false]25028---[nio- 
9101-exec-1] 

ication$$EnhancerBySpringCGLIB$$d8228493 :===<call] trace-1>=== 

--trace-2 

INEO[trace-2,{410ab57afd5c145,e9a377dc2268bc29,falsel]23112---[nio- 
9102-exec-1| 

ication$$EnhancerBySpringCGLIB$$e6cb4078 :===<call trace-2>=== 

从 上 面 的 控制 台 输 出 内 容 中 ， 我 们 可 以 看 到 多 二 一 = [trace- 
1,f410ab57afd5c145,a9f2118fa2019684 ‘false] 的 日 志 信 息 ， I 
tL 分 布 式 服务 跟踪 的 重要 组 成 部 分 ， 每 个 值 的 全 含义 如 下 所 述 

第 一 个 值 : trace-1， 它 记 录 了 应 用 的 名 称 ， 也 就 是 
i 中 spring.application.name 参 数 配置 的 属性 。 

e 第 二 个 值 : f410ab57afd5c145,Spring Cloud Sleuth 生 成 的 一 个 ID， 称 
为 Trace ID， 它 用 来 标识 一 条 请 求 链 路 。 一 条 请 求 链 路 中 包含 一 个 Trace 
ID， 多 个 Span ID。 

e 第 三 个 值 : a9f2118fa2019684,Spring Cloud Sleuth 生成 的 另外 一 个 
TD “ 称 为 Span ID 第 表示 一 个 基本 的 工作 单元 ， 比 太一 个 Tai 
求 。 
第 四 个 值 : false， 表 示 是 否 要 将 该 信息 输出 到 Zipkin 等 服务 中 来 收 
集 和 展示 。 
上 面 四 个 值 中 的 Trace ID 和 Span ID 是 Spring Cloud Sleuth 实 现 分 布 式 











服务 跟踪 的 核心 。 在 一 次 服务 请 求 链 路 的 调用 过 程 中 ， 会 保持 并 传递 同 
一 个 Trace ID， 从 而 将 整个 分 布 于 不 同 微服 务 进程 中 的 请 求 跟 踊 信息 串 
联 起 来 。 以 上 面 输出 内 容 为 例 ，trace-1 和 trace-2 同 属于 一 个 前 端 服务 请 
求 来 源 ， 所 以 它们 的 Trace ID 是 相同 的 ， 处 于 同一 条 请 求 链 路 中 。 





未 原 了 
eR di 60 它 主要 包括 下 面 两 个 


e 为 了 实现 请 求 跟 踪 ， 当 请 求 发 送 到 分 布 式 系统 的 入 口 端 点 时 ， 只 需 
要 服务 跟踪 框架 为 该 请 求 创建 一 个 唯一 的 跟踪 标识 ， 同 时 在 分 布 式 系 统 
内 部 流转 的 时 候 ， 框 架 始 终 保持 传递 该 唯一 标识 ， 直 到 返回 给 请 求 方 为 
止 ， 这 个 唯一 标识 就 是 前 文中 提 到 的 Trace ID。 通 过 Trace ID 的 记录 ， 我 
们 就 能 将 所 有 请 求 过 程 的 日 志 关 联 起 来 。 

e 为 了 统计 各 处 理 单元 的 时 间 延 迟 ， 当 请 求 到 达 各 个 服务 组 件 时 ， 或 
是 处 理 逻 辑 到 达 某 个 状态 时 ， 也 通过 一 个 唯一 标识 来 标记 它 的 开始 、 具 
体 过 程 以 及 结束 ， 访 标识 就 是 前 文中 提 到 的 Span ” ID。 对 于 每 个 Span 来 
说 ， 它 必须 有 开始 和 结束 两 个 节点 ， 通 过 记录 开始 Span 和 结束 Span 的 时 
间 惟 ， 就 能 统计 出 该 Span 的 时 间 延 人 运 ， 除 了 时 间 惟 记录 之 外 ， 它 还 可 以 
包含 一 些 其 他 元 数据 ， 比 如 事件 名 称 、 请 求 信息 等 。 

在 快速 入 门 示 例 中 ， 我 们 轻松 实现 了 日 志 级 别 的 跟踪 信息 接 入 ， 这 
完全 归功 于 spring-cloud-starter-sleuth 组 件 的 实现 。 在 Spring ”Boot 应 用 
中 ， 通 过 在 工程 中 引入 spring-cloud-starter-sleuth 依赖 之 后 ， 它 会 自动 为 
当前 应 用 构建 起 各 通信 通道 的 跟踪 机 制 ， 比 如 : 

e 通 过 诸如 RabbitMQ、Kafka (或 者 其 他 任何 Spring Cloud Stream 绑 
定 器 实现 的 消 奶 中 间 件 ) 传递 的 请 求 。 

e 通 过 Zuul 代 理 传递 的 请 求 。 

e 通 过 RestTemplate 发 起 的 请 求 。 

在 快速 入 门 示例 中 ， 由 于 trace-1 对 trace-2 发 起 的 请 求 是 通过 
RestTemplate 实 现 的 ， 所 以 spring-cloud-starter-sleuth 组 件 会 对 该 请 求 进 
行 处 理 。 在 发 送 到 trace-2 之 前 ，Sleuth 会 在 该 请 求 的 Header 中 增加 实现 
跟 踩 需要 的 重要 信息 ， 主 要 有 下 面 这 几 个 《更 多 关于 头 信息 的 定义 可 以 
通过 查看 org.springframework.cloud.sleuth.Span 的 源码 获取 ) 。 

eX-B3-TraceId: 一 条 请 求 链 路 〈Trace) 的 唯一 标识 ， 必 需 的 值 。 

eX-B3-SpanId: 一 个 工作 单元 (Span) 的 唯一 标识 ， 必 需 的 值 。 
eX-B3-ParentSpanId: 标识 当前 工作 单元 所 属 的 上 一 个 工作 单元 ， 
Root Span 〈 请 求 链 路 的 第 一 个 工作 单元 ) 的 该 值 为 空 。 

eX-B3-Sampled: 是 否 被 抽样 输出 的 标志 ，1 表 示 需 要 被 输出 ，0 表 示 
不 需要 被 输出 。 

eX-Span-Name: 工作 单元 的 名 称 。 

可 以 通过 对 trace-2 的 实现 做 一 些 修改 来 输出 这 些 头 部 信息 ， 有 共 体 如 





























下 : 
@RequestMapping (value="/trace-2",method=RequestMethod.GET) 
public String trace (HttpServletRequest request) { 
logger.info ("===<call trace-2,Traceld={},Spanld={}>===", 
request.getHeader ("X-B3-Traceld") ,request.getHeader ("X-B3- 

SpanId") ) ; 

return "Trace ; 


} 

通过 上 面 的 改造 ， 我 们 再 运行 快速 入 门 的 示例 内 容 ， 并 发 起 对 trace- 
1 的 接口 访问 ， 可 以 得 到 如 下 输出 内 容 。 其 中 在 trace-2 的 控制 台中 ， 输 
出 了 当前 正在 处 理 的 TraceID 和 SpanId 信 息 。 

--trace-1 

INEO[trace-1,a6e9175ffd5d2c88,8524f519b8a9e399,true]10532---[nio- 
9101-exec-2] 

icationEnhancerBySpringCGLIB27aa9624 :===<call trace-1>=== 








--trace-2 
INEO[trace-2,a6e9175ffd5d2c88,ce60dcf1e2ed918f,true]1208---[nio- 
9102-exec-3jicationEnhancerBySpringCGLIBa7d84797 :===<call trace- 


2,Traceld=a6e9175ffd5d2c88, 
SpanId=be4949ec115e554e>=== 
为 了 更 直观 地 观察 跟踪 信息 ， 我 们 还 可 以 在 application.properties 中 
增加 下 面 的 配置 : 
logging.level.org.springframework.web.servlet.DispatcherServlet=DEBU( 
通过 将 Spring MVC 的 请 求 分 发 日 志 级 别 调整 为 DEBUG 级 别 ， 我 们 可 
以 看 到 更 多 跟踪 信息 : 








出 样 ! 反 自 


通过 Trace ID 和 Span ID 已 经 实现 了 对 分 布 式 系统 中 的 请 求 跟 踪 ， 而 
记录 的 跟踪 信息 最 终 会 被 分 析 系 统 收集 起 来 ， 并 用 来 实现 对 分 布 式 系统 
的 监控 和 分 析 功 能 ， 比 如 ， 预 警 延 迟 过 长 的 请 求 链 路 、 查 询 请 求 链 路 的 
调用 明细 等 。 此 时 ， 我 们 在 对 接 分 析 系 统 时 就 会 碰 到 一 个 问题 : 分 析 系 
统 在 收集 跟踪 信息 的 时 候 ， 需 要 收集 多 少 跟 踩 信息 才 合适 呢 ? 

理论 上 来 说 ， 我 们 收集 的 跟踪 信息 越 多 就 可 以 越 好 地 反映 出 系统 的 
实际 运行 情况 ， 并 给 出 更 精准 的 预警 和 分 析 。 但 是 在 高 并 发 的 分 布 式 系 
统 运 行 时 ， 大 量 的 请 求 调用 会 产生 海量 的 跟踪 日 志 信 息 ， 如 果 收 集 过 多 
的 跟踪 信息 将 会 对 整个 分 布 式 系统 的 性 能 造成 一 定 的 影响 ， 同 时 保存 大 
量 的 日 志 信 息 也 需要 不 少 的 存储 开销 。 所 以 ， 在 Sleuth 中 采用 了 抽象 收 
集 的 方式 来 为 跟踪 信息 打上 收集 标记 ， 也 就 是 我 们 之 前 在 日 志 信 息 中 看 
到 的 第 4 个 布尔 类 型 的 值 ， 它 代表 了 该 信息 是 否 要 被 后 续 的 跟踪 信息 收 
集 器 获取 和 存储 。 

Sleuth 中 的 抽样 收集 策略 是 通过 Sampler 接 口 实现 的 ， 它 的 定义 如 
下 : 









































public interface Sampler { 

/炒米 

* (Oreturm true if the span is not null and should be exported to the tracing 
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boolean isSampled (Span span) ; 

} 

通过 实现 isSampled 方 法 ，Spring Cloud Sleuth 会 在 产生 跟踪 信息 的 时 
候 调用 它 来 为 跟踪 信息 生成 是 否 要 被 收集 的 标志 。 需 要 注意 的 是 ， 即 使 
isSampled 返 回 了 false， 它 仅 代 表 该 跟踪 信息 不 被 输出 到 后 续 对 接 的 远程 
分 析 系 统 《〈 比 如 Zipkin) ， 对 于 请 求 的 跟踪 活动 依然 会 进行 ， 所 以 我 们 
在 日 志 中 还 是 能 看 到 收集 标识 为 false 的 记录 。 

默认 情况 下 ，Sleuth 会 使 用 PercentageBasedSampler 实 现 的 抽样 策 
略 ， 以 请 求 百 分 比 的 方式 配置 和 收集 跟踪 信息 。 我 们 可 以 通过 在 
application.properties 中 配置 下 面 的 参数 对 其 百分比 值 进行 设置 ， 它 的 默 
认 值 为 0.1， 代 表 收 集 10% 的 请 求 跟踪 信息 。 

Spring.sleuth.Sampler.percentage=0.1 

在 开发 调试 期 间 ， 通 常会 收集 全 部 跟踪 信息 并 输出 到 远程 仓库 ， 我 
们 可 以 将 其 值 设 置 为 1， 或 者 也 可 以 通过 创建 AlwaysSampler 的 Bean( 它 





实现 的 isSampled 方 法 始终 返回 true) 来 禾 羡 默认 的 
PercentageBasedSampler 策 略 ， 比 如 : 
Bean 
public AlwaysSampler defaultSampler () { 
return new AlwaysSampler () ; 


} 

在 实际 使 用 时 ， 通 过 与 Span 对 象 中 存储 信息 的 配合 ， 我 们 可 以 根据 
实际 情况 做 出 更 贴近 需求 的 抽样 策略 ， 比 如 实现 一 个 仅 包 含 指定 Tag 的 
抽样 策略 : 

public class TagSampler implements Sampler { 

private String tag; 

public TagSampler (String tag) { 

this.tag=tag; 








(DOverride 
public boolean isSampled (Span span) { 
return span.tags () .get (tag) !=null; 








} 

由 于 跟踪 日 志 信 息 数 据 的 价值 往往 仅 在 最 近 的 一 段 时 间 内 非常 有 
用 ， 比 如 一 周 。 那 么 我 们 在 设计 抽样 策略 时 ， 主 要 考虑 在 不 对 系统 造成 
明显 性 能 影响 的 情况 下 ， 以 在 日 志保 留 时 间 窗 内 充分 利用 存储 空间 的 原 
则 来 实现 抽样 集 略 。 


与 Logstash 整 合 


通过 之 前 的 准备 与 整合 ， 我 们 已 经 为 trace-1 和 trace-2 引 入 了 Spring 
Cloud Sleuth 的 基础 模块 spring-cloud-starter-sleuth， 实 现 了 在 各 个 微服 务 
的 日 志 信息 中 添加 跟踪 信息 的 功能 。 但 是 ， 由 于 日 志文 件 都 离散 地 存储 
在 各 个 服务 实例 的 文件 系统 之 上 上， 仅仅 通过 得 看 日 志文 件 来 分 析 我 们 的 
请 求 链 路 依然 是 一 件 相 当 厅 烦 的 事 ， 所 以 我 们 还 需要 一 些 工 具 来 帮助 集 
中 收集 、 存 储 和 搜索 这 些 跟 踩 信 息 。 引 入 基于 日 志 的 分 析 系 统 是 一 个 不 
， 的 选择 ， 比 如 ELK 平 台 ， 它 可 以 轻松 地 帮助 我 们 收集 和 存储 这 些 跟踪 

同时 在 需要 的 时 候 我 们 也 可 以 根据 Trace ID 来 轻松 地 搜索 出 对 应 
请 Rs 的 明细 日 志 。 

ELK 平 台 主 要 由 ElasticSearch、 Logstash 和 Kibana 三 个 开源 工具 组 
成 。 

eElasticSearch 是 一 个 开源 分 布 式 搜索 引擎 ， 它 的 特点 有 : 分 布 式 ， 
零 配置 ， 上 自动 发 现 ， 索 引 目 动 分 睫 ， 索 引 副 本 机 制 ，RESTful ”风格 接 
口 ， 多 数据 源 ， 自 动 搜索 负载 等 。 

eLogstash 是 一 个 完全 开源 的 工具 ， 它 可 以 对 日 志 进 行 收 集 、 过 滤 ， 
并 将 其 存储 供 以 后 使 用 。 

eKibana 人 它 可 以 为 Logstash 和 
ElasticSearch 提 供 日 志 分 析 友 好 的 Web 界面 ， 可 以 帮助 汇总 、 分 析 和 搜 
过 重要 数据 日 志 。 

Cloud Slenih 在 与 ELK 平台 整合 使 用 时 ， 实 际 上 只 要 实现 与 
负责 日 志 收 集 HJLogstash 完 成 数据 对 接 即 可 ， 所 以 我 们 需要 为 Logstash 
SON 格 式 的 日 志 输 出 。 由 于 Spring ” Boot 应 用 默认 使 用 logback 来 记 
录 日 志 ， 而 Logstash 自 身 也 有 对 logback 日 志 工 具 的 支持 工具 ， 所 以 我 们 
可 以 言 找 通过 让 logback 的 配置 中 增加 对 Logstash 的 Appender， 就 能 非常 
方便 地 将 日 志 转 换 成 以 JSON 的 格式 存储 和 输出 了 。 

下 面 我 们 来 详细 介绍 一 下 在 快速 入 门 示 例 的 基础 上 ， 如 何 实 现 面 回 
Logstash 的 日 志 输 出 配置 

e 在 pom.xml 依 赖 中 引入 logstash-logback-encoder 依 赖 ， 有 具体 如 下 : 

<dependency> 

<groupld>net.logstash.logback</groupld> 

<artifactId>logstash-logback-encoder</artifactId> 

<version>4.6</version> 

</dependency> 


e 在 工程 /resource 目 录 下 创建 bootstrap.properties 配 置 文件 ， 将 

















Spring.application.name=trace-1 配 置 移动 到 该 文件 中 去 。 由 于 logback- 
spring.xml ”的 加 载 在 。 application.properties ”之 前 ， 所 以 之 前 的 配置 
logbackspring.xml 无 法 获取 spring.application.name 属性 ， 因 此 这 里 将 该 
属性 移动 到 最 先 加 载 的 bootstrap.properties 配 置 文件 中 。 

e 在 工程 /resource 目 录 下 创建 logback 配 置 文件 logback-spring.xml， 具 
体内 容 如 下 : 


<? Xml version="1.0" encoding="UTF-8"? > 


<configuration> 

<include 
resource="org/springframework/boot/logging/logback/defaults.xml"/> 

<springProperty scope="context" name="springAppName" 


source="spring. 

application.name"/> 

<!-- 日 志 在 工程 中 的 输出 位 置 --> 

<property name="LOG FILE" value="${BUILD_FOLDER:- 
build}/${springAppName}"/> 

<!-- 控 制 台 的 日 志 输 出 样式 --> 

<property name="CONSOLE_LOG_ PATTERN" 

value="%clr (%d{yyyy-MM-dd HH:mm:ss.SSS}) {faint} 
%clr (${LOG_LEVEL_ PATTERN:-%5p}) %alr ([${springAppName:- 
},%X{X-B3-Traceld:-},%X{X-B3-SpanIld:-},%X{X-Span-Expo rt:-}]) 
{yellow} %clr (${PID:-}) {magenta} %clr (---) {faint} 
%clr ([%15.15t]) {faint} %c lr (%-40.40logger{39}) {cyan} %clr (:) 
{faint} %m%n$ {LOG_ EXCEPTION_CONVERSION_ WORD:-%wE x}"/> 

<!-- 控 制 台 Appender--> 

<appender name="console" 
class="ch.qos.logback.core.ConsoleAppender"> 

<filter class="ch.qos.logback.classic .filter.ThresholdFilter"> 

<level>INFO</level> 

</filter> 

<encoder> 

<pattern>${CONSOLE LOG PATTERN}</pattern> 

<charset>utf8</charset> 

</encoder> 

</appender> 

<!-- 为 logstash 输 出 的 JSON 格 式 的 Appender--> 

<appender name="]ogstash" 


class="ch.qos.logback.core.rolling.RollingFileAppender"> 

<file>${LOG_FILE}.json</file> 

<rollingPolicy 
class="ch.gqos.logback.core.rolling.TimeBasedRollingPolicy"> 

<fileNamePattern>${LOG_ FILE}.json.%d{yyyy-MM- 
dd}.gz</fileNamePattern> 

<maxHistory>7</maxHistory> 

</rollingPolicy> 

<encoder 
class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder"> 

<providers> 

<timestamp> 

<timeZone>UTC</timeZone> 

</timestamp> 

<pattern> 

<pattern>{ 

"severity": "%level", 

"service": "${springAppName:-}", 

"trace": "%X{X-B3-Traceld:-}", 

"span": "%X{X-B3-Spanld:-}", 

"exportable": "%X{X-Span-Export:-}", 

"pid": "${PID:-}", 

"thread": "%thread", 

"class": "%logger{40}", 

"rest": "9%0message"} 

</pattern> 

</pattern> 

</providers> 

</encoder> 

</appender> 

<root level="INFO"> 

<appender-ref ref="console"/> 

<appender-ref ref="logstash"/> 

</root> 

对 Logstash 的 支持 主要 通过 名 为 logstash 的 Appender 实 现 ， 内 容 并 不 
复杂 ， 主 要 是 对 日 志 信 息 的 格式 化 处 理 ， 上 面 为 了 方便 调试 得 看， 我 
们 先 将 JSON 格 式 的 日 志 输 出 到 文件 中 。 





完成 上 面 的 改造 之 后 ， 我 们 再 将 快速 入 门 的 示例 运行 起 来 ， 并 发 起 
对 trace-1 的 接口 访问 。 此 时 可 以 在 trace-1 和 trace-2 的 工程 目录 下 发 现 有 
一 个 build 目 录 ， 下 面 分 别 创建 了 以 各 自 应 用 名 称 命名 的 JSON 文件 ， 访 
文件 就 是 在 ”logback-spring.xml 中 配置 的 名 为 logstash 的 Appender 输 出 的 
日 志文 件 ， 其 中 记录 了 类 似 下 面 格式 的 JSON 日 志 : 

{"(@timestamp":"2016-12- 
04106:57:58.970+00:00","severity":"INFO","service":"trac e- 
1","trace":"589ee5f7b860132f","span":"a9e891273affb7fc","exportable":"fals 
nio-9101-exec-1","class":"c.d.TraceApplication$$EnhancerBy 








SpringCGLIB$$a9604da6","rest":"===<call] trace-1>==="} 
{"@timestamp":"2016-12- 
04106:57:59.061+00:00","severity":"INFO","service":"trac e- 


1","trace":"589ee5f7b860132f","span":"2df8511ddf3d79a2","exportable":"fal 
nio-9101-exec-1","class":"0.s.c.a.AnnotationConfigApplicat 
ionContext",'"rest":"Refreshing 
org.springframework.context.annotation.AnnotationConfigApplicationContex 
startup date[Sun Dec 04 14:57:59 CST 2016j]; 
parent:org.Springframework.boot.context.embedded.AnnotationConfigEmbed 
text(D4b8c8f15"} 

除了 可 以 通过 上 面 的 方式 生成 JSON ”文件 外 ， 还 可 以 使 用 


LogstashTcpSocketAppender 将 日 志 内 容 直 接 通 过 Tcp Socket 输 出 到 
Logstash 服 务 端 ， 比 如 : 
<appender name="|logstash" 


class="net.logstash.logback.appender.LogstashTcpSocket Appender"> 
<destination>127.0.0.1:9250</destination> 


</appender> 


与 Zipkin 整 合 


虽然 通过 ELK 平 台 提 供 的 收集 、 存 储 、 搜 索 等 强大 功能 ， 我 们 对 跟 
踪 信 息 的 管理 和 使 用 已 经 变 得 非常 便利 。 但 是 ， 在 ELK 平 台中 的 数据 分 
析 维 度 缺 少 对 请 求 链 路 中 各 阶段 时 间 延 迟 的 关注 ， 很 多 时 候 我 们 退 溯 请 
求 链 路 的 一 个 原因 是 为 了 找 出 整个 调用 链 路 中 出 现 延 迟 过 高 的 瓶颈 源 ， 
或 为 了 实现 对 分 布 式 系统 做 延迟 监控 等 与 时 间 消 耗 相 关 的 需求 ， 这 时 候 
类 似 ELK 这 样 的 日 志 分 析 系 统 就 显得 有 些 乏 力 了 。 对 于 这 样 的 问题 ， 我 
们 就 可 以 引入 Zipkin 来 得 以 轻松 解决 。 

Zipkin 是 Twitter 的 一 个 开源 项 目 ， 它 基于 Google ”Dapper 实现 。 我 们 
可 以 使 用 它 来 收集 各 个 服务 器 上 请 求 链 路 的 跟踪 数据 ， 并 通过 它 提 供 的 
REST API 接 口 来 辅助 查询 跟踪 数据 以 实现 对 分 布 式 系 统 的 监控 程序 ， 
从 而 及 时 发 现 系统 中 出 现 的 延迟 升 高 问题 并 找 出 系统 性 能 瓶 贷 的 根源 。 
除了 面向 开发 的 API 接口 之 外 ， 它 还 提供 了 方便 的 UI 组 件 来 帮助 我 们 
直观 地 搜索 跟踪 信息 和 分 析 请 求 链 路 明细 ， 比 如 可 以 查询 茶 段 时 间 内 各 
用 户 请 求 的 处 理 时 间 等 。 

下 图 展示 了 Zipkin 的 基础 架构 ， 它 主要 由 4 个 核心 组 件 构成 。 


eCollector: 收集 器 组 件 ， 它 主要 处 理 从 外 部 系统 发 送 过 来 的 跟踪 信 
娠 ， 将 这 些 信息 转换 为 Zipkin 内 部 处 理 的 Span 格 式 ， 以 支持 后 续 的 存 
储 、 分 析 、 展 示 等 功能 。 

eStorage: 存储 组 件 ， 它 主要 处 理 收集 器 接收 到 的 跟踪 信息 ， 默 认 会 
将 这 些 信息 存储 在 内 存 中 。 我 们 也 可 以 修改 此 存储 策略 ， 通 过 使 用 其 他 
存储 组 件 将 跟踪 信息 存储 到 数据 库 中 。 

eRESTful API:API 组 件 ， 它 主要 用 来 提供 外 部 访问 接口 。 比 如 给 客 
户 端 展示 跟踪 信息 ， 或 是 外 接 系 统 访问 以 实现 监控 等 。 

eWeb UI:UI 组 件 ， 基 于 API 组 件 实现 的 上 层 应 用 。 通 过 UI 组 件 ， 用 
户 可 以 方便 而 又 直观 地 查询 和 分 析 跟 踪 信 息 。 


HTTP 收 集 


在 Spring Cloud Sleuth 中 对 Zipkin 的 整合 进行 了 自动 化 配置 的 封装 ， 
所 以 我 们 可 以 很 轻松 地 引入 和 使 用 它 。 下 面 我 们 来 详细 介绍 一 下 Sleuth 
与 Zipkin 的 基础 整合 过 程 ， 主 要 分 为 以 下 两 步 。 

第 一 步 : 搭建 Zipkin Server 

e 创 建 一 个 基础 的 Spring Boot 应 用 ， 命 名 为 zipkin-server， 并 在 

















pom.xml 中 引入 Zipkin Server 的 相关 依赖 ， 具 体 如 下 : 
<parent> 
<groupId>org.Springframework.boot</groupId> 
<artifactId>spring-boot-starter-parent</artifactId> 
<version>1.3.7.RELEASE</version> 
<relativePath/> 
</parent> 
<dependencies> 
<dependency> 
<groupId>io.zipkin.java</groupId> 
<artifactId>zipkin-server</artifactId> 
</dependency> 
<dependency> 
<groupId>io.zipkin.java</groupId> 
<artifactId>zipkin-autoconfigure-ui</artifactId> 
</dependency> 
</dependencies> 
<dependencyManagement> 
<dependencies> 
<dependency> 
<groupId>org.Springframework.cloud</groupId> 
<artifactId>spring-cloud-dependencies</artifactId> 
<version>Brixton.SR5</version> 
<type>pom</type> 
<scope>import</scope> 
</dependency> 
</dependencies> 
</dependencyManagement> 
e 创 建 应 用 主 类 ZipkinApplication， 使 用 @EnableZipkinServer 注 解 来 

启动 Zipkin Server， 具 体 如 下 : 
@EnableZipkinServer 
SpringBootApplication 
public class ZipkinApplication { 
public static void main (String[]args) { 
SpringApplication.run (ZipkinApplication.class,args) ; 
} 


} 


e 在 application.properties 中 做 一 些 简 单 配 置 ， 比 如 设置 服务 端口 号 为 
9411 (客户 端 整 合 时 ， 目 动 化 配置 会 连接 9411 端 口 ， 所 以 在 服务 端 设置 
了 端口 为 9411 的 话 ， 客 户 端 可 以 省 去 这 个 配置 ) 。 

spring.application.name=zipkin-server 

server.port=9411 

创建 完 上 述 工 程 之 后 ， 我 们 将 其 启动 起 来 ， 并 访问 
http:/localhost:9411/， 可 以 看 到 如 下 图 所 示 的 Zipkin 管 理 页 面 : 


第 二 步 : 为 应 用 引入 和 配置 Zipkin 服 务 

在 完成 了 Zipkin Server 的 搭建 之 后 ， 我 们 还 需要 对 应 用 做 一 些 配置 ， 
以 实现 将 跟踪 信息 输出 到 Zipkin Server。 我 们 以 之 前 实现 的 trace-1 和 
trace-2 为 例 ， 对 它们 做 以 下 改造 。 

e 在 trace-1 和 trace-2 的 pom.xml 中 引入 spring-cloud-sleuth-zipkin 依 赖 ， 

有 具体 如 下 所 示 。 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-sleuth-zipkin</artifactId> 

</dependency> 

e 在 trace-1 和 trace-2 的 application.properties 中 增加 Zipkin Server 的 配置 

言 息 ， 具 体 如 下 所 示 (如 果 在 zip-server 应 用 中 ， 我 们 将 其 端口 设置 为 
9411， 并 且 均 在 本 地 调试 的 话 ， 也 可 以 不 配置 该 参数 ， 因 为 默认 值 就 是 
http:/localhost:9411) 。 

spring.zipkin.base-url=http://localhost:9411 

测试 与 分 析 

到 这 里 我 们 已 经 完成 了 接 入 Zipkin Server 的 所 有 基本 工作 ， 可 以 继 
续 将 eureka-server、trace-1 和 trace-2 启 动 起 来 ， 然 后 做 一 些 测试 ， 以 对 它 
的 运行 机 制 有 一 些 初步 的 理解 。 

我 们 先 来 同 trace-1 的 接口 发 送 几 个 请 求 http://localhost:9101/trace-1。 
当 在 日 志 中 出 现 跟 踊 信息 的 最 后 一 个 值 为 tue 的 时 候 ， 说 明 该 跟踪 信息 
会 输出 给 Zipkin Server， 所 以 此 时 可 以 在 Zipkin Server 的 管理 页 面 中 选 
择 合适 的 查询 条 件 ， 单 击 Find Traces 按 钮 ， 就 可 以 查询 出 刚才 在 日 志 中 
出 现 的 跟踪 信息 了 《也 可 以 根据 日 志 中 的 Trace ID， 在 页 面 右上 角 的 输 
入 框 中 来 搜索 ) ， 页 面 如 下 所 示 。 


单 击 下 方 trace-1 端 点 的 跟踪 信息 ， 还 可 以 得 到 Sleuth 跟 踊 到 的 详细 信 
恩 ， 其 中 包括 我 们 关注 的 请 求 时 间 消 耗 等 。 

















单 击 导航 栏 中 的 Dependencies 菜 单 ， 还 可 以 查看 Zipkin Server 根 据 跟 
踩 信 息 分 析 生 成 的 系统 请 求 链 路 依赖 关系 图 ， 如 下 网 所 示 。 
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Spring Cloud Sleuth 在 整合 Zipkin 时 ， 不 仅 实 现 了 以 HTTP 的 方式 收集 
跟踪 信息 ， 还 实现 了 通过 消息 中 间 件 来 对 跟踪 信息 进行 异步 收集 的 封 
装 。 通 过 结合 Spring Cloud Stream， 我 们 可 以 非常 轻松 地 让 应 用 客户 端 
将 跟踪 信息 输出 到 消 妃 中 间 件 上 ， 同 时 Zipkin 服 务 端 从 消息 中 间 件 上 噶 
步 地 消费 这 些 跟 中 信息 。 

接 下 来 ， 我 们 基于 之 前 实现 的 trace-1 和 trace-2 应 用 以 及 zipkin-server 
服务 端 做 一 些 改造 ， 以 实现 通过 消 乱 中 间 件 来 收集 跟 踩 信息。 改造 的 内 
容 非 党 简单， 只 需要 对 项 目 依赖 和 配置 文件 做 一 些 调整 马上 就 能 实现 。 
下 面 我 们 分 别 对 客户 端 和 服务 端的 改造 内 容 做 详细 说 明 。 

第 一 步 : 修改 客户 端 trace-1 和 trace-2 

e 为 了 让 trace-1 和 trace-2 在 产生 跟踪 信息 之 后 ， 能 够 将 抽样 记录 输出 
到 消息 中 间 件 ， 除 了 需要 之 前 引入 的 spring-cloud-starter-sleuth 依赖 之 
外 ， 还 需要 引入 Zipkin 对 Spring Cloud Stream 的 扩展 依赖 Spring-cloud- 
sleuthstream 以 及 基于 Spring Cloud Stream 实现 的 消息 中 间 件 绑 定 器 依 
赖 。 以 使 用 RabbitMQ 为 例 ， 我 们 可 以 加 入 如 下 依赖 : 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-sleuth-stream</artifactId> 

</dependency> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-stream-rabbit</artifactId> 

</dependency> 

e 在 application.properties ”配置 中 去 掉 http ”方式 实现 时 使 用 的 
spring.zipkin.base-url 参 数 ， 并 根据 实际 部 署 情况 ， 增 加 消 妃 中 间 件 的 相 
关 配 置 ， 比 如 下 面 这 些 关 于 RabbitMQ 的 配置 信息 : 

Spring.rabbitmdqd.host=localhost 

spring.rabbitmq.port=5672 

spring.rabbitmq.username=springcloud 

spring.rabbitmq.password=123456 

第 二 步 : 修改 zipkin-server 服 务 端 











为 了 让 zipkin-server 服务 端 能 够 从 消息 中 间 件 中 获取 跟踪 信息 ， 我 
们 只 需要 在 pom.xml 中 引入 针对 消 虫 中 间 件 收集 封 效 的 服务 端 依 赖 
spring-cloud-sleuth-zipkin ”stream， 同 时 为 了 文 持 具体 使 用 的 消 奶 中 间 
件 ， 我 们 还 需要 引入 针对 消息 中 间 件 的 绑 定 堪 实 现 。 比 如 以 使 用 
RabbitMQ 为 例 ， 我 们 可 以 在 依赖 中 增加 如 下 内 容 : 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-sleuth-zipkin-stream</artifactId> 

</dependency> 

<dependency> 

<groupId>org.Springframework.cloud</groupId> 

<artifactId>spring-cloud-starter-stream-rabbit</artifactId> 

</dependency> 

<dependency> 

<groupId>io.zipkin.java</groupId> 

<artifactId>zipkin-autoconfigure-ui</artifactId> 

</dependency> 

其 中 ，spring-cloud-sleuth-zipkin-stream 依 赖 是 实现 从 消息 中 间 件 收集 
跟踪 信息 的 核心 封闭， 其 中 包含 了 用 于 整合 消息 中 间 件 的 核心 依赖 、 
Zipkin 服务 端的 核心 依赖 ， 以 及 一 些 其 他 通常 会 被 使 用 的 依赖 《比如 ， 
用 于 扩展 数据 存储 的 依赖 、 用 于 支持 测试 的 依赖 等 ，。 但 是 ， 需 要 注意 
的 是 ， 这 个 包 里 并 没有 引入 zipkin 的 前 端 依赖 zipkinautoconfigure-ui， 
为 了 方便 使 用 ， 我 们 在 这 里 也 引用 了 它 。 

测试 与 分 析 

在 完成 了 上 述 改 造 内容 之 后 ， 我 们 继续 将 eureka-server、trace-1 和 
trace-2、zipkin-server 都 启动 起 来 ， 同 时 确保 RabbitMQ 也 处 于 运行 状 
态 。 此 时 ， 我 们 可 以 在 RabbitMQ 的 控制 页 面 中 看 到 一 个 名 为 sleuth 的 交 
换 右 ， 它 就 是 Zipkin 的 消 妃 中 间 件 收集 左 实 现 使 用 的 默认 主题 。 


最 后 ， 我 们 使 用 之 前 的 验证 方法 ， 通 过 同 ”trace-1 的 接口 发 送 几 个 请 
求 http://localhost:9101/trace-1。 当 有 被 抽样 收集 的 跟踪 信息 时 (调试 时 
我 们 可 以 设置 AlwaysSampler 抽 样机 制 来 让 每 个 跟 踩 信息 都 被 收集 ) ， 
我 们 可 以 在 RabbitMQ 的 控制 页 面 中 发 现 有 消息 被 发 送 到 了 sleuth 交 换 器 
中 。 同 时 再 到 Zipkin 服 务 端的 Web 页 面 中 也 能 够 搜索 到 相应 的 跟踪 信 
恩 ， 那 么 我 们 使 用 消息 中 间 件 来 收集 跟 踩 信息 的 任务 到 这 里 就 完成 了 。 

















在 本 市 内 容 之 前 ， 我 们 已 经 对 如 何 引 入 Sleuth 跟 踪 信 息 和 搭建 Zipkin 
服务 端 分 析 跟 踪 延 人 运 的 过 程 做 了 详细 的 介绍 ， 相 信 大 家 对 于 Sleuth 和 
Zipkin 己 经 有 了 一 定 的 感性 认识 。 接 下 来 ， 我 们 介绍 一 下 关于 Zipkin 收 
集 跟踪 信息 的 过 程 细 节 ， 以 帮助 我 们 更 好 地 理解 Sleuth 生 产 跟踪 信息 以 
及 输出 跟踪 信息 的 整体 过 程 和 工作 原理 。 

数据 模型 

我 们 先 来 看 看 Zipkin 中 关于 跟踪 信息 的 一 些 基础 概念 。 由 于 Zipkin 
的 实现 借鉴 了 Google 的 Dapper， 所 以 它们 有 痢 类 似 的 核心 术语 ， 主 要 有 
下 面 几 项 内 容 。 

eSpan: 它 代 表 了 一 个 基础 的 工作 单元 。 我 们 以 HTTP 请 求 为 例 ， 一 
次 完整 的 请 求 过 程 在 客户 端 和 服务 端 都 会 产生 多 个 不 同 的 事件 状态 〈 比 
如 下 面 所 说 的 4 个 核心 Annotation 所 标识 的 不 同 阶段 ) 。 对 于 同一 个 请 求 
来 说 ， 它 们 属于 一 个 工作 单元 ， 所 以 同一 HTTP 请 求 过 程 中 的 4 个 
Annotation 同 属于 一 个 Span。 每 一 个 不 同 的 工作 单元 都 通过 一 个 64 位 的 
ID 来 唯一 标识 ， 称 为 Span ID。 另外， 在 工作 单元 中 还 存储 了 一 个 用 来 
串联 其 他 工作 单元 的 ID， 它 也 通过 一 个 64 位 的 ID 来 唯一 标识 ， 称 为 
Trace ID 。 在 同一 条 请 求 链 路 中 的 不 同 工 作 单元 都 会 有 不 同 的 Span ID， 
但 是 它们 的 Trace ID 是 相同 的 ， 所 以 通过 Trace ID 可 以 将 一 次 请 求 中 依赖 
的 所 有 依赖 请 求 串 联 起 来 形成 请 求 链 路 。 除 了 这 两 个 核心 的 ID 之 外 ， 
Span 中 还 存储 了 一 些 其 他 信息 ， 比 如 ， 描 述 信息 、 事 件 时 间 惟 、 
Annotation 的 键 值 对 属性 、 上 一 级 工作 单元 的 Span ID 等 。 

eTrace: 它 是 由 一 系列 具有 相同 Trace ID 的 Span 串 联 形成 的 一 个 树 状 
结构 。 在 复杂 的 分 布 式 系统 中 ， 每 一 个 外 部 请 求 通常 都 会 产生 一 个 复杂 
的 树 状 结构 的 Trace。 

eAnnotation: 它 用 来 及 时 地 记录 一 个 事件 的 存在 。 我 们 可 以 把 
Annotation 理 解 为 一 个 包含 有 时 间 惟 的 事件 标签 ， 对 于 一 个 HITP 请 求 来 
说 ， 在 Sleuth 中 定义 了 下 面 4 个 核心 Annotation 来 标识 一 个 请 求 的 开始 和 
结束 。 














加 Cs (Client Send) : 该 Annotation 用 来 记录 客户 端 发 起 了 一 个 请 求 ， 
同时 它 也 标识 了 这 个 HTTP 请 求 的 开始 。 

国 ST (Server ”Received) : 该 Annotation 用 来 记录 服务 端 接收 到 了 请 
求 ， 并 准备 开始 处 理 它 。 通 过 计算 sr 与 cs 两 个 Annotation 的 时 间 惟 之 差 ， 
我 们 可 以 得 到 当前 HTTP 请 求 的 网 络 延迟 。 

加 SS (Server Send) : 该 Annotation 用 来 记录 服务 端 处 理 完 请 求 后 准 
备 发 送 请 求 响应 信息 。 通 过 计算 ss 与 Sr 两 个 Annotation 的 时 间 惟 之 差 ， 我 
们 可 以 得 到 当前 服务 端 处 理 请 求 的 时 间 消 耗 。 

加 Cr (Client Received) : 该 Annotation 用 来 记录 客户 端 接收 到 服务 端 








的 回复 ， 同 时 它 也 标识 了 这 个 HTTP 请 求 的 结束 。 通 过 计算 cr 与 cs 两 个 
Annotation 的 时 间 惟 之 产 ， 我 们 可 以 得 到 该 http 请求 从 客户 端 发 起 到 接 
收服 务 端 啊 应 的 总 时 间 消 耗 。 

eBinaryAnnotation: 它 用 来 对 跟踪 信息 添加 一 些 额 外 的 补充 说 明 ， 
一 般 以 键 值 对 的 方式 出 现 。 比 如 ， 在 记录 HTTP 请 求 接收 后 执行 具体 业 
务 逻 辑 时 ， 此 时 并 没有 默认 的 Annotation 来 标识 该 事件 状态 ， 但 是 有 
BinaryAnnotation 信 息 对 其 进行 补充 。 

收集 机 制 

在 理解 了 Zipkin 的 各 个 基本 概念 之 后 ， 下 面 我 们 结合 前 面 章节 中 实现 
的 例子 来 详细 介绍 和 理解 Spring Cloud Sleuth 是 如 何 对 请 求 调用 链 路 完成 
跟踪 信息 的 生产 、 输 出 和 后 续 处 理 的 。 

首先 ， 我 们 来 看 看 Sleuth 在 请 求 调用 时 是 怎样 来 记录 和 生成 跟踪 信息 
的 。 下 图 展示 了 本 市 中 实现 示例 的 运行 全 过 程 : 客户 端 发 送 了 一 个 
HTTP 请 求 到 trace-1,trace-1 依 赖 于 trace-2 的 服务 ， 所 以 trace-1 再 发 送 一 个 
HTTP 请 求 到 trace-2， 符 trace-2 返 回 啊 应 之 后 ，trace-1 再 组 织 啊 应 结果 返 
回 给 客户 端 。 


在 上 图 的 请 求 过 程 中 ， 我 们 为 整个 调用 过 程 标 记 了 10 个 标签 ， 它 们 
分 别 代 表 了 该 请 求 链 路 运行 过 程 中 记录 的 几 个 重要 事件 状态 。 根 据 事件 
发 生 的 时 间 顺 序 我 们 为 这 些 标签 做 了 从 小 到 大 的 编号 ，1 代 表 请 求 的 开 
始 、10 代 表 请 求 的 结束 。 每 个 标签 中 记录 了 一 些 上 面 提 到 过 的 核心 元 
素 : Trace ID、Span ID 以 及 Annotation。 由 于 这 些 标签 都 源 自 一 个 请 
求 ， 所 以 它们 的 Trace ID 相 同 ， 而 标签 1 和 标签 10 是 起 始 和 结束 节点 ， 它 
们 的 Trace ID 与 Span ID 是 相同 的 。 

根据 Span ID， 我 们 可 以 发 现在 这 些 标签 中 一 共产 生 了 4 个 不 同 ID 的 
Span， 这 4 个 Span 分 别 代 表 了 这 样 4 个 工作 单元 。 

eSpan T: 记录 了 客户 端 请 求 到 达 trace-1 和 trace-1 发 送 请 求 啊 应 的 两 
个 事件 ， 它 可 以 计算 出 客户 端 请 求 响 应 过 程 的 总 延 人 运 时 间 。 

eSpan A: 记录 了 trace-1 应 用 在 接收 到 客户 端 请 求 之 后 调用 处 理 方法 
的 开始 和 结束 两 个 事件 ， 它 可 以 计算 出 trace-1 应 用 用 于 处 理 客户 端 请 求 
时 ， 内 部 逻辑 花费 的 时 间 延 迟 。 

eSpan B: 记录 了 trace-1 应 用 发 送 请 求 给 trace-2 应 用 、trace-2 应 用 接 
收 请 求 ，trace-2 应 用 发 送 啊 应 、trace-1 应 用 接收 啊 应 4 个 事件 ， 它 可 以 计 
算出 trace-1 调 用 trace-2 的 总 体 依 赖 时 间 〈cr-cs) ， 也 可 以 计算 出 trace-1 
到 trace-2 的 网 络 延 迟 〈sr-cs) ， 还 可 以 计算 出 trace-2 应 用 用 于 处 理 客户 
病 请 求 的 内 部 逻辑 花费 的 时 间 延 人 运 (ss-sr) 。 

eSpan C: 记录 了 trace-2 应 用 在 接收 到 trace-1 的 请 求 之 后 调用 处 理 方 




















法 的 开始 和 结束 两 个 事件 ， 它 可 以 计算 出 trace-2 应 用 人 处理 来 自 trace-1 的 
请 求 时 ， 内 部 逻辑 花费 的 时 间 延 迟 。 

在 图 中 展现 的 这 个 4 个 Span 正 好 对 应 了 Zipkin 查 看 跟踪 详细 页 面 中 的 
显示 内 容 ， 它 们 的 对 应 关系 如 下 图 所 示 。 


仔细 的 读者 可 能 还 有 这 样 一 个 疑惑 : 我 们 在 Zipkin 服 务 端 查询 跟踪 信 
恩 时 《〈 如 下 图 所 示 ) ， 在 查询 结果 页 面 中 显示 的 spans 是 5， 而 单 击 进入 
跟踪 明细 页 面 时 ， 显 示 的 Total Spans 又 是 4， 为 什么 会 出 现 span 数 量 不 一 
致 的 情况 呢 ? 


实际 上 这 两 边 的 span 数 量 内 容 有 不 同 的 含义 ， 碍 询 结 末 页 面 中 的 5 
spans 代 表 了 总 共 接 收 的 Span 数 量 ， 而 在 详细 页 面 中 的 Total Spans 则 是 对 
接收 Span 进 行 合并 后 的 结果 ， 也 就 是 前 文中 我 们 介绍 的 4 个 不 同 ID 的 
Span 内 容 。 下 面 我 们 来 详细 研究 一 下 Zipkin 服 务 端 收集 客户 端 跟踪 信息 
的 过 程 ， 看 看 它 到 底 收 到 了 哪些 具体 的 Span 内 容 ， 从 而 来 理解 Zipkin 中 
收集 到 的 Span 总 数量 。 

为 了 更 直观 地 观察 Zipkin 服 务 端的 收集 过 程 ， 我 们 可 以 对 之 前 实现 的 
消 有 息 中 间 件 方式 收集 跟踪 信息 的 程序 进行 调试 。 通 过 在 Zipkin 服 务 端 的 
消 恩 通道 监听 程序 中 增加 断 点 ， 我 们 能 清楚 地 知道 客户 端 都 发 送 了 什么 
信息 到 Zipkin 的 服务 端 。 在 spring-cloudsleuth-zipkin-stream 依 赖 包 中 的 
代码 并 不 多 ， 很 容易 就 能 找到 定义 消 恩 通道 监听 的 实现 类 : | 
org.springframework.cloud.sleuth.zipkin.stream.ZipkinMessageListener。 它 
的 具体 实现 如 下 所 示 ， 其 中 SleuthSink.INPUT 定 义 了 监听 的 输入 通道 ， 
默认 会 使 用 名 为 sleuth 的 主题 ， 我 们 也 可 以 通过 Spring Cloud Stream 的 配 
置 对 其 进行 修改 。 

@MessageEndpoint 

@Conditional (NotSleuthStreamClient.class) 

public class ZipkinMessageListener { 

final Collector collector; 

@ServiceActivator (inputChannel=SleuthSink.INPUT) 

public void sink (Spans input) { 

List<zipkin.Span> 
converted=ConvertToZipkinSpanL ist.convert (input) ; 

this.collector.accept (converted,Callback.NOOP) ; 

} 























从 通道 监听 方法 的 定义 中 我 们 可 以 看 到 ，Sleuth 与 Zipkin 在 整合 的 时 
候 是 由 两 个 不 同 的 Span 定 义 的 ， 一 个 是 消息 通道 的 输入 对 象 
org.springframework.cloud.sleuth.stream.Spans， 它 是 Sleuth 中 定义 的 用 于 
消息 通道 传输 的 Span 对 象 。 每 个 消息 中 包含 的 Span 信 息 定 义 在 
org.Springframework.cloud.sleuth.Span 对 象 中 ， 但 是 真正 在 Zipkin 服 务 端 
使 用 的 并 非 这 个 Span 对 象 ， 而 是 Zipkin 上 自己 的 zipkin.Span 对 象 。 所 以 ， 
在 消息 通道 监听 处 理 方法 中 ， 对 Sleuth 的 Span 做 了 处 理 ， 每 次 接收 到 
Sleuth 的 Span 之 后 束 将 其 转换 成 Zipkin 的 Span。 

下 面 我 们 尝试 在 sink (Spans input) 方法 实现 的 第 一 行 代码 中 加 入 断 
点 ， 并 辐 trace-1 发 送 一 个 请 求 ， 触 发 跟 踩 信息 发 送 到 RabbitMQ 上 。 此 时 
我 们 通过 DEBUG 横 式 可 以 发 现 消 息 通 道中 都 接收 到 了 两 次 输入 ， 一 次 
来 自 trace-1， 一 次 来 自 trace-2。 下 面 两 张 图 分 别 展示 了 来 自 trace-1 和 
trace-2 输 出 的 跟踪 消息 ， 其 中 trace-1 的 跟踪 消息 包含 了 3 条 Span 信 息 ， 
trace-2 的 跟 踩 消息 包含 了 2 条 Span 人 信息， 所 以 在 这 个 请 求 调 用 链 上 ， 一 
共 发 送 了 5 个 Span 信 息 ， 也 就 是 我 们 在 Zipkin 搜 索 结 果 页 面 中 看 到 的 
Spans 的 数量 信息 。 


点 开 一 个 具体 的 Span 内 容 ， 我 们 可 以 看 到 如 下 所 示 的 结构 ， 它 记录 
了 Sleuth 中 定义 的 Span 详 细 人 信息， 包括 该 Span 的 开始 时 间 、 结 束 时 间 、 
Span 的 名 称 、Trace ID、Span ID、Tags (对 应 Zipkin 中 的 
BinaryAnnotation) 、Logs 《对 应 Zipkin 中 的 Annotation〉 等 之 前 提 到 过 
的 核心 跟踪 信息 。 


介绍 到 这 里 仔细 的 读者 可 能 会 有 一 个 疑惑 ， 在 明细 信息 中 展示 的 
Trace ID 和 Span ID 的 值 为 什么 与 列表 展示 的 概要 信息 中 的 Trace ID 和 
Span ID 的 值 不 一 样 呢 ? 实际 上 ，Trace ID 和 Span ID 都 是 使 用 long 类 型 存 
储 的 ， 在 DEBUG 模 式 下 查看 其 明细 时 自然 是 long 类 型 ， 也 就 是 它 的 原 
始 值 ， 但 是 在 得 看 Span 对 象 的 时 候 ， 我 们 看 到 的 是 通过 toString〈) 函 
数 处 理 过 的 值 。 从 Sleuth 的 Span 源 码 中 我 们 可 以 看 到 如 下 定义 ， 在 输出 
Trace ID 和 Span ID 时 都 调用 了 idToHex 函 数 将 long 类 型 的 值 转换 成 了 十 
六 进 制 的 字符 串 值 ， 所 以 在 DEBUG 时 我 们 会 看 到 两 个 不 一 样 的 值 。 

public String toString () { 























return "[Trace: "+idToHex (this.traceld) +",Span: 
"+idToHex (this.spanId) 
+",Parent: "+getParentIdIfPresent () 


+",exportable:"+this.exportable+"]"; 


} 


public static String idToHex (longid) { 
return Long.toHexString (id) ; 


} 

在 接收 到 Sleuth 之 后 ， 我 们 将 程序 继续 执行 下 去 ， 可 以 看 到 经 过 转换 
后 的 Zipkin 的 Span 内 容 ， 它 们 保存 在 一 个 名 为 converted 的 列表 中 ， 具 体 
内 容 如 下 所 示 : 


上 图 展示 了 转换 后 的 Zipkin ”Span 对 象 的 详细 内 容 ， 可 以 看 到 很 多 熟 
悉 的 名 称 ， 也 就 是 之 前 介绍 的 关于 Zipkin 中 的 各 个 基本 概念 。 而 这 些 基 
本 概念 的 值 我 们 也 都 可 以 在 之 前 Sleuth 的 原始 Span 中 找到 ， 其 中 
Annotations 和 BinaryAnnotations 有 一 些 特殊 。 在 Sleuth 定 义 的 Span 中 没有 
使 用 相同 的 名 称 ， 而 是 使 用 了 logs 和 tags 来 命名 。 从 这 里 的 详细 信息 
中 ， 我 们 可 以 直观 地 看 到 Annotations 和 BinaryAnnotations 的 作用 ， 其 中 
Annotations 中 存储 了 当前 Span 包 含 的 各 种 事件 状态 以 及 对 应 事件 状态 的 
时 间 戳 ， 而 BinaryAnnotations 则 存储 了 对 事件 的 补充 信息 ， 比 如 上 图 中 
存储 的 就 是 该 HITP 请 求 的 细节 描述 信息 ， 除 此 之 外 ， 它 也 可 以 存储 对 
调用 函数 的 详细 摘 述 (如 下 图 所 示 )。 


下 面 我 们 再 来 详细 看 看 通过 调试 消息 监听 程序 接收 到 的 这 5 个 Span 内 
容 。 首 先 ， 可 以 发 现 ， 每 个 Span 中 都 包含 有 3 个 ID 信息 ， 其 中 除了 标识 
Span 上 自身 的 ID 以 及 用 来 标识 整 条 链 路 的 traceId 之 外 ， 还 有 一 个 之 前 没有 
提 过 的 parentId， 它 是 用 来 标识 各 Span 父 子 关 系 的 ID 〈 它 的 值 来 自 于 上 
一 步 执行 单元 Span 的 ID) 。 通 过 parentId 的 定义 我 们 可 以 为 每 个 Span 
找到 它 的 前 置 节点 ， 从 而 定位 每 个 Span 在 请 求 调用 链 中 的 确切 位 置 。 
在 每 条 调用 链 路 中 都 有 一 个 特殊 的 Span， 它 的 parentId 为 null， 这 类 Span 
我 们 称 它 为 Root Span， 也 融 是 这 条 请 求 调 用 链 的 根 节 点 。 为 了 和 弄 清楚 这 
些 Span 之 间 的 关系 ， 我 们 可 以 从 Root Span 开 始 来 整理 出 整 条 链 路 的 Span 
Re 了 我 们 从 Root Span 开 始 ， 根 据 各 个 Span 的 父子 关系 整理 


上 表 中 的 Host 代 表 了 该 Span 是 从 哪个 应 用 发 送 过 来 的 ， Span ID 是 当 
前 Span 的 唯一 标识 ; Parent Span ID 代表 了 上 一 执行 单元 的 Span ID; 
Annotation 代 表 了 该 Span 中 记录 的 事件 (这 里 主要 用 来 记录 http 请 求 的 4 
个 阶段 ， 表 中 内 容 进 行 了 省 略 处 理 ， 只 记录 了 Annotation 名 称 (sr 代表 
服务 端 接收 请 求 ，ss 代 表 服 务 端 发 送 请 求 ，cs 代 表 客 户 端 发 送 请 求 ，cr 
代表 客户 端 接收 请 求 ) ， 省 略 了 一 些 其 他 细节 信息 ， 比 如 服务 名 、 时 间 
稚 、IP 地 址 、 端 口号 等 信息 ) ; BinaryAnnotation 代 表 了 事件 的 补充 信息 




















(Sleuth 的 原始 Span 记 录 更 为 详细 ，Zipkin 的 Span 处 理 后 会 去 掉 一 些 内 

容 ， 对 于 有 Annotation 标 识 的 信息 ， 不 再 使 用 Binary Annotation 补充 ， 
在 上 表 中 我 们 只 记录 了 服务 名 、 类 名 、 方 法 名 ， 同 样 省 略 了 一 些 其 他 信 
息 ， 比 如 时 间 戳 、 卫 地址 、 端 口号 等 信息 ) 。 

通过 收集 到 的 Zipkin Span 详 细 信 息 ， 我 们 很 容易 将 它们 与 本 节 开 始 
时 介绍 的 一 次 调用 链 路 中 的 10 个 标签 内 容 联 系 起 来 。 

eSpan ID=T 的 标签 有 2 个 ， 分 别 是 序号 1 和 10， 它 们 分 别 表示 这 次 请 
求 的 开始 和 结束 。 它 们 对 应 了 上 表 中 ID 为 e9a933ec50d180d6 的 Span， 该 
Span 的 内 容 在 标签 10 执 行 结束 后 ， 由 trace-1 将 标签 1 和 10 合 并 成 一 个 
Span 发 送 给 Zipkin Server。 

eSpan ID=A 的 标签 有 2 个 ， 分 别 是 序号 2 和 9， 它 们 分 别 表示 了 trace-1 
请 求 接 收 后 ， 有 具体 处 理 方法 调用 的 开始 和 结束 。 该 Span 的 内 容 在 标签 9 
执行 结束 后 ， 由 trace-1 将 标签 2 和 9 合并 成 一 个 Span 发 送 给 Zipkin 
Server。 

eSpan ID=B 的 标签 有 4 个 ， 分 别 是 序号 3、4、7、8， 该 Span 比 较 特 
丈 ， 它 的 产生 器 越 了 两 个 实例 ， 其 中 标签 3 和 8 是 由 trace-1 生 成 的 ， 而 标 
签 4 和 7 则 是 由 trace-2 生 成 的 ， 所 以 该 标签 会 拆 分 成 两 个 Span 内 容 发 送 
给 Zipkin Server。trace-1 会 在 标签 8 结束 的 时 候 将 标签 3 和 8 合并 成 一 个 
Span 发 送 给 Zipkin Server， 而 trace-2 会 在 标签 7 结束 的 时 候 将 标签 4 和 7 合 
并 成 一 个 Span 发 送 给 Zipkin Server。 

eSpan ID=C 的 标签 有 2 个 ， 分 别 是 序号 5 和 6， 它 们 分 别 表 示 了 trace-2 
请 求 接 收 后 ， 有 具体 处 理 方法 调用 的 开始 和 结束 。 该 Span 的 内 容 在 标签 6 
执行 结束 后 ， 由 trace-2 将 标签 2 和 9 合并 成 一 个 Span 发 送 给 Zipkin 
Server。 

所 以 ， 根 据 上 面 的 分 析 ，Zipkin 总 共 会 收 到 5 个 Span: 一 个 Span T， 
一 个 Span A， 两 个 Span B， 一 个 Span C。 结 合 之 前 请 求 链 路 的 标签 图 和 
这 里 的 Span 记 录 ， 我 们 可 以 总 结 出 如 下 图 所 示 的 Span 收 集 过 程 ， 读 者 可 
以 参照 此 图 来 理解 Span 收 集 过 程 的 处 理 逻 辑 以 及 各 个 Span 之 间 的 关系 。 


虽然 ，Zipkin 服 务 端 接收 到 了 5 个 Span， 但 就 如 前 文中 分 析 的 那样 ， 

其 中 有 两 个 Span ID=B 的 标签 ， 由 于 它们 来 自 于 同一 个 HITP 请 求 
(trace-1 对 trace-2 的 服务 调用 )〉 ， 概 念 上 它们 属于 同一 个 工作 单元 ， 

此 Zipkin 服务 端 在 前 端 展现 分 析 详 情 时 会 将 这 两 个 Span 合 并 显示 ， 而 合 
并 后 的 Span 数 量 就 是 在 请 求 链 路 详情 页 面 中 Total Spans 的 数量 。 

下 图 是 本 章 示例 的 一 个 请 求 链 路 详情 页 面 ， 在 页 面 中 显示 了 各 个 
Span 的 延迟 统计 ， 其 中 第 三 条 Span 信 息 就 是 trace-1 对 trace-2 的 HTTP 请 求 
调用 ， 通 过 单 击 它 可 以 查看 该 Span 的 详细 信息 。 单 击 后 会 以 模 态 框 的 方 


























式 弹 出 Span 详 细 信息 《如 图 下 半 部 分 所 示 ) ， 在 弹出 框 中 详细 展示 了 
Span 的 Annotation 和 BinaryAnnotation 信 息 ， 在 Annotation 区 域 我 们 可 以 
看 到 它 同 时 包含 了 trace-1 和 trace-2 发 送 的 Span 信 息 ， 而 在 
BinaryAnnotation 区 域 则 展示 了 该 HTTP 请 求 的 详细 信息 。 





默认 情况 下 ，Zipkin ”Server 会 将 跟踪 信息 存储 在 内 存 中 ， 每 次 重启 
Zipkin Server 都 会 使 之 前 收集 的 跟踪 信息 丢失 ， 并 且 当 有 大 量 跟踪 信息 
时 我 们 的 内 存 存储 也 会 成 为 瓶 贷 ， 所 以 通常 情况 下 我 们 都 需要 将 跟踪 信 
恩 对 接 到 外 部 存储 组 件 中 去 ， 比 如 使 用 MySQL 存 储 。 

Zipkin 的 Storage 组 件 中 默认 提供 了 对 MySQL 的 支持 ， 所 以 我 们 可 
以 很 轻松 地 为 zipkin-server 增加 MySQL 存储 功能 。 下 面 我 们 详细 介绍 
基于 消息 中 间 件 实现 的 zipkin-server 应 用 ， 对 其 进行 MySQL 存 储 扩展 的 
详细 过 程 。 

第 一 步 : 为 zipkin-server 添 加 依赖 

为 了 让 zipkin-server 能 够 访问 MySQL 数 据 库 ， 我 们 需要 在 它 的 
pom.xml 文 件 中 增加 如 下 依赖 ， 以 支持 对 MySQL 的 访问 : 

<dependency> 

<groupId>org.Springframework.boot</groupId> 

<artifactId>spring-boot-starter-jdbc</artifactId> 

</dependency> 

<dependency> 

<groupld>mysql</groupId> 

<artifactId>mysql-connector-java</artifactId> 

</dependency> 

<dependency> 

<groupld>org.jo0g</groupld> 

<artifactId>joogq</artifactId> 

<version>3.8.0</version> 

</dependency> 

这 里 需要 注意 加 入 org.jooq 的 依赖 ， 并 不 是 因为 缺少 这 个 依赖 而 引入 
它 ， 而 是 为 了 解决 该 版 本 存在 的 一 个 Bug。 当 不 引入 该 依赖 的 时 候 ， 会 
使 用 默认 的 依赖 ， 但 是 默认 情况 下 引入 的 依赖 并 非 3.8.0， 当 有 跟踪 信息 
被 zipkin-server 收 集 并 入 库 时 会 报 如 下 错误 : 


0.$.C.S.Z.Stream.ZipkinMessageListener  : Cannot store Spans 




















[e7aca79a855ff80a.30671a9177f24801<:114fftd85950b117b， 


e7aca79a855ff80a.114ffd85950b117b<:d8ac47672741466c]due to 
VerifyError (class 
zipkin.storage.mysql.internal.generated.tables.ZipkinSpans Overrides 


final method 
getSchema. () Lorg/joog/Schema;) 
java.lang.VerifyError: class 
Zipkin.storage.mysql.internal.generated.tables.ZipkinSpans Overrides 
final method 
getSchema. () Lorg/joog/Schema; 


0.S.C.S.i.m.MessagingSpanExtractor : Deprecated trace headers 
detected. 

Please upgrade Sleuth to 1.1 or start sending headers present in the 
TraceMessageHeaders 

Class 


0.$.C.S.Z.Stream.ZipkinMessageListener : Cannot store Spans 

[8ce053ed8c2410a0.d6b63783a69485d8<:9ebc8131ebdb07fc， 

8ce053ed8c2410a0.9ebc8131ebdb07fc<:8ce053ed8c2410a0， 

8ce053ed8c2410a0.8ce053ed8c2410a0<:8ce053ed8c2410a0]due to 

VerifyError (zipkin/storage/mysql/internal/generated/tables/ZipkinSpans 

从 报错 信息 中 我 们 可 以 看 到 
VerifyError (zipkin/storage/mysdql/internal/generated/tables/ZipkinSpans) 

这 一 句 ， 从 ZipkinSpans 的 源码 中 我 们 可 以 看 到 如 下 内 容 : 

@@Generated ( 

value={ 

"http://www.joog.org", 

"jOOQ version:3.8.0" 

} 

comments="This class is generated by jOOQ" 

) 

从 注解 中 可 以 看 到 ，ZipkinSpans 对 象 是 通过 jOOQ 3.8.0 生 成 出 来 
的 ， 但 是 当 工程 不 加 入 上 面 的 org.jooq 依 赖 时 ，jOoQ 的 版 本 是 3.7.4， 正 
是 因为 这 里 的 版 本 不 一 致 导致 了 上 面 错 误 的 出 现 。 所 以 ， 如 果 读 者 在 使 
用 其 他 版 本 的 Spring Cloud Sleuth 出 现 类 似 错误 时 ， 可 以 看 看 是 否 是 由 这 
个 原因 引起 的 。 





二 步 : 在 MySQL 中 创建 用 于 Zipkin 存 储 的 Schema 

这 里 需要 注意 一 点 ，Zipkin Server 实现 关系 型 数据 库存 储 时 ， 不 同 
版 本 对 数据 库 表 结构 都 有 一 些 变 化 。 当 跨 版 本 使 用 时 很 容易 出 现 各 种 整 
合 问 题 ， 所 以 尽量 使 用 对 应 版 本 的 脚本 来 创建 Schema。 同 时 ，Zipkin 实 
现 的 MySQL 存 储 仅 在 MySQL 5.6-5.7 版 本 中 测试 过 ， 所 以 尽量 使 用 对 应 
版 本 的 MySQL， 以 避免 产生 不 可 预知 的 问题 。 

本 书 中 我 们 使 用 了 Spring Cloud 的 Brixton.SR5 版 本 ， 通 过 查看 依赖 关 
系 可 以 知道 已 使 用 的 Zipkin 版 本 为 1.1.5， | 
该 版 本 并 下 载 创 建 表 结 构 的 脚本 。 另 外 ， 也 可 以 在 本 地 依赖 中 找到 该 脚 
本 ， 下 图 展示 了 mysql.sql 脚本 在 本 地 依赖 中 的 具体 位 置 : 


从 上 图 中 我 们 还 可 以 知道 ，MySQL 的 存储 支持 是 通过 zipkin- 
autoconfigurestorage-mysql 依 赖 实现 的 ， 但 是 我 们 之 前 为 什么 没有 引入 
该 依赖 呢 ? 这 是 由 于 我 们 改造 的 工程 基础 是 消 妃 中 间 件 实现 的 示例 ， 之 
前 提 到 过 ， 在 该 示例 中 引入 的 spring-cloud-sleuth-zipkin-stream 依 赖 包含 
了 各 个 常用 的 依赖 组 件 ， 其 中 就 包括 了 对 MySQL 的 支持 依赖 ， 所 以 我 
们 这 里 并 不 需要 再 手工 添加 它 。 当 然 ， 如 果 不 是 基于 该 示例 ， 而 是 通过 
http 实现 的 收集 示例 来 改造 时 ， 束 需要 自己 引入 对 zipkin-autoconfigure- 
storage-mysql 的 依赖 了 。 

在 获取 创建 表 结 构 的 SQL 文件 之 后 ， 我 们 可 以 在 MySQL 中 手工 创建 
名 为 zipkin 的 Schema， 并 运行 mysql.sql 脚本 来 创建 表 ek 除 此 之 
外 ， 也 可 以 通过 在 程序 中 进行 配置 的 方式 让 其 自动 初始 化 ， 只 需要 在 
application.properties 中 增加 如 下 配置 : 

spring.datasource.schema=classpath:/mysql.sql 

spring.datasource.url=jdbc:mysql://localhost:3306/zipkin 
spring.datasource.username=root 

spring.datasource.password=123456 

spring.datasrouce.continueOnError=true 

spring.datasrouce.initialize=true 

通过 启动 程序 ， Spring Boot 的 JDBC 模 块 会 自动 地 为 我 们 根据 指定 的 
SQL 文件 来 创建 表 结 构 。 我 们 可 以 得 到 如 下 两 张 表 。 

ezipkin_spans: 存储 Span 信 息 的 表 。 

ezipkin_annotations: 存储 Annotation 信 息 的 表 。 

第 三 步 : 换 存 储 类 型 

通过 第 二 我们 己 经 让 zipkin-server 连接 到 MySQL， 并 且 创 建 
用 于 存储 跟 防 信 . 思 的 ”Schema。 下 面 我 们 只 需要 再 做 一 个 简单 配置 ， 
zipkin-server 的 存储 切换 到 MySQL 即 可 ， 具 体 配 置 如 下 : 























zipkin.storage.type=mysql 

测试 与 验证 

到 这 里 ， 我 们 就 已 经 完成 了 将 zipkin-server 从 内 存 存 储 跟 踪 信 息 切 
换 为 MySQL 存 储 跟 踪 信 息 的 改造 。 最 后 ， 我 们 继续 使 用 之 前 的 验证 方 
法 ， 通 过 同 ”trace-1 的 接口 发 送 几 个 请 求 http://localhost:9101/trace-1， 当 
有 被 抽样 收集 的 跟踪 信息 时 (调试 时 可 以 设置 AlwaysSampler 抽 样机 制 
来 让 每 个 跟踪 信息 都 被 收集 ) ， 查 看 MySQL 中 的 两 张 表 ， 可 以 得 到 类 
似 下 面 的 数据 信息 。 

ezipkin_spans 表 





ezipkin_annotations 表 


表 中 所 存储 的 信息 我 们 已 经 非常 熟悉 ， 之 前 分 析 的 内 容 都 可 以 在 这 
两 张 表 中 体现 出 来 。 比 如 Span 的 数量 问题 ， 从 zipkin_spans 表 中 ， 我 们 
可 以 看 到 一 次 请 求 调用 链 路 的 跟踪 信息 产生 了 4 条 span 数 据 ， 也 束 是 
说 ， 在 入 zipkin_spans 表 的 时 候 ， 已 经 对 收集 的 span 信息 进行 了 人 合并， 所 
以 在 查询 详细 信息 时 ， 不 需要 每 次 都 来 计算 合并 span。 而 在 
zipkin_annotations 表 中 ， 通 过 span_id 字段 可 以 关联 到 每 个 具体 工作 单 
元 的 详细 信息 ， 同 时 根据 endpoint_service_name 和 span_id 字 段 还 可 以 计 
算出 一 次 请 求 调用 链 路 中 总 共 接 收 到 的 span 数 量 。 

Zipkin 在 存储 方面 除了 对 “MySQL 有 扩展 组 件 之 外 ， 还 实现 了 对 
Cassandra 和 ElasticSearch 的 支持 扩展 。 具 体 的 整合 方式 与 MySQL 的 整合 
类 似 ， 读 者 可 自行 查阅 Zipkin 的 官方 文档 做 进一步 的 了 解 。 














API 坟 口 


Zipkin 不 仅 提供 了 UI 模 块 让 用 户 可 以 使 用 Web 页 面 来 方便 地 得 看 跟踪 
信息 ， 它 还 提供 了 丰富 的 RESTful API 接 口供 用 户 在 第 三 方 系统 中 调用 
来 定制 自己 的 跟踪 信息 展示 或 监控 。 我 们 可 以 在 Zipkin Server 启 动 时 的 
控制 台 或 日 志 中 找到 Zipkin 服 务 端 提供 的 RESTful API 定 义 ， 比 如 下 面 的 
日 志 片 段 : 

Ss.W.s.m.m.a.RequestMappingHandlerMapping : Mapped 

"{[/api/vl/dependencies],methods=[GET],produces= 
[application/json]}"... 

Ss.W.s.m.m.a.RequestMappingHandlerMapping : Mapped 

"{[/api/v1l/trace/{traceld}],methods=[GET],produces= 
[application/json]}"... 








Ss.W.s.m.m.a.RequestMappingHandlerMapping : Mapped 
"{[/api/vi/traces],methods=[GET],produces=[application/json]}"... 
Ss.W.s.m.m.a.RequestMappingHandlerMapping : Mapped 
"{[/api/vil/services],methods=[GET]}"... 
Ss.W.s.m.m.a.RequestMappingHandlerMapping : Mapped 
"{[/api/v1l/spans],methods=[GET]}"... 
Ss.W.s.m.m.a.RequestMappingHandlerMapping : Mapped 
"{[/api/v1l/spans],methods=[POST]}"... 
Ss.wW.s.m.m.a.RequestMappingHandlerMapping : Mapped 
"{[/api/v1l/spans],methods=[POST],consumes=[application/x-thrift]}"... 
可 以 看 到 Zipkin Server 提 供 的 API 接 口 都 以 /apiv1 路 径 作 为 前 级 ， 它 
们 的 具体 功能 整理 如 下 : 


更 多 关于 接口 的 请 求 参数 和 请 求 返 回 格式 等 细节 说 明 ， 可 以 通过 访 
问 Zipkin 官方 的 API 页 面 http://zipkin.io/zipkin-api/ 来 查看 ， 帮 助 我 们 根 
据 自 身 系统 架构 来 访问 Zipkin ， Server 以 定制 自己 的 Dashboard 或 监控 系 
统 。 实 际 上 ，Zipkin 的 UI 模 块 也 是 基于 RESTful API 接 口 来 实现 的 ， 有 兴 
趣 的 读者 可 以 通过 浏览 器 的 开发 者 模式 来 得 看 每 个 页 面 发 起 的 请 求 ， 以 
此 作为 调用 样 例 来 参考 。 





了 侍 录 A Starter POMSs 


下 面 整理 了 针对 Spring Boot 1.3.7 版 本 的 Starter POMs 模 块 。 
续 表 


2017 年 1 月 8 日 ， 总 算 赶 在 过 年 前 基本 完成 了 本 书 的 编写 。 自 博客 上 
发 表 第 一 篇 关于 Spring ”Cloud 的 文章 开始 ， 持 续 地 研究 、 实 践 与 输出 相 
关内 容 已 经 有 半年 之 多 。 而 编写 本 书 是 从 2016 年 9 月 开始 的 ， 本 以 为 采 
用 当时 最 新 的 Release 版 本 可 以 让 本 书 内 容 紧 跟 潮流 ， 然 而 Spring Cloud 
的 发 展 远 比 我 所 想象 的 要 快 得 多 。 在 这 4 个 月 的 时 间 中 ，Brixton 版 本 从 
SR5 升 级 到 了 SR7， 而 Camden 版 本 也 开始 进入 Release 阶 段 ， 并 持续 升级 
到 了 SR3。 人 惊叹 Spring ”Cloud 高 速 发 展 的 同时 ， 也 让 我 坚定 了 对 Spring 
Cloud 的 文 持 。 相 信 在 未 来 的 几 年 内 ， 在 企业 应 用 架构 的 选择 上 ，Spring 
Cloud 一 定 会 开始 办 露头 角 。 

虽然 本 书 内 容 是 基于 Brixton SR5 版 本 实现 的 ， 但 经 调试 均 可 以 兼容 
目前 最 新 的 Brixton SR7 和 Camden SR3 版 本 。 不 过 ， 对 于 部 分 写法 在 
Camden 中 被 标注 了 废弃 状态 ， 比 如 Spring Cloud Stream 中 的 一 些 注 解 
等 。 对 于 Spring _ Cloud 的 更 新 内 容 ， 相 信也 是 大 部 分 读者 希望 可 以 持续 
获得 的 信息 ， 由 于 笔者 自身 也 在 实践 这 部 分 内 容 ， 因 此 在 完成 本 书 之 
后 ， 我 也 会 持续 关注 Spring Cloud 的 发 展 ， 并 继续 开始 更 新 博客 内 容 ， 
主要 关注 于 Spring ”Cloud 的 新 特性 以 及 实践 中 碰 到 的 一 些 问题 。 读 者 可 
以 关注 我 的 博客 : http://blog.didispace.com， 或 是 我 的 微 信 公众 号 : 
didispace， 以 获得 最 新 的 分 享 信息 。 

在 去 年 创建 的 Spring Cloud 中 文 社区 论坛 
Chttp:Wbbs.springcloud.com.cn) ， 目 前 在 许 进 的 牵头 和 帮助 下 ， 已 经 与 
一 些 其 他 优秀 资源 做 了 整合 ， 目 前 归 入 ”Spring Cloud ”中国 社 区 
(http://springcloud.cn) 统一 管理 。 由 于 2016 年 大 家 都 忙于 各 自 的 工 
作 ， 还 没有 对 社区 的 运作 〈 包 括 文档 贡献 和 知识 分 享 等 ) 做 出 一 定 的 规 
划 。 在 2017 年 ， 我 们 会 抽出 时 间 来 规划 一 些 对 Spring ”Cloud 知 识 分 至 、 
文档 贡献 等 相关 的 公益 性 活动 ， 以 帮助 所 有 Spring Cloud 爱好 者 与 实践 
者 共同 成 长 。 

下 面 是 关于 本 书 的 代码 案例 资源 ， 主 要 维护 于 GitHub 和 开源 中 国 
ee” 内 容 或 示例 有 任何 疑问 均 可 以 在 这 里 
可 我 提问 。 

eGitHub:https://github.com/dyc87112/SpringCloudBook 

e 开 源 中 国 : http://git.oschina.net/didispace/SpringCloudBook 

在 本 书 的 最 后 ， 我 要 特别 感谢 我 的 家 人 在 这 段 时 间 内 给 予 的 文 持 ， 

让 我 能 够 挤 出 更 多 的 时 间 来 完成 本 书 的 编写 。 同 时 ， 也 要 感谢 Spring 















































Cloud 中 国 社区 的 朋友 、 关 注 我 博客 的 读者 ， 以 及 交流 群 中 给 我 提出 过 
不 少 优秀 建议 的 网 友 ， 正 是 因为 有 了 大 家 的 文 持 ， 才 能 让 我 一 二 坚持 写 
完 本 书 。 即 便 如 此 ， 本 书 还 是 无 法 禾 盖 Spring Cloud 的 全 部 ， 但 是 后 续 
我 会 通过 博客 等 其 他 渠道 紧 跟 Spring ” ”Cloud 的 发 展 ， 分 享 更 多 实战 经 验 
和 研究 成 果 。 





